{Quick Tip} Why is my workflow not showing up in Workflow Profiler in Plugin Registration Tool

Recently I was conducting a training where I was demoing on how to debug a Custom Workflow activity step using the profiler in plugin registration tool. So here I was explaining to them to first click on “Profile Workflow” button on the plugin registration tool. For starters, here it is in the screenshot below

image

image

And as I said – “Select your workflow”, I suddenly see a hand raised informing me that he is not able to view the workflow created by him.

Verified with all other’s and they are able to see the their respective workflows.

I just thought – “Must be some silly error.” But I was soon to be proved wrong.

Situations like this could be tough when asked all of a sudden. But my memory didn’t reach came to my rescue this time. I realized that while playing with the workflow, he has changed the owner of the workflow to someone else. And hence the workflow is not showing up in the workflow profiler.

So remember, if you are profiling a workflow, make sure the user with whom you have logged in to Plugin Registration Tool and the the owner of the workflow, should be the same person. Otherwise the workflow won’t simply appear in the ‘Profile Workflow’ list.

Hope this helps and saves you some time before you waste couple of hours in this.

 

-Debajit Dutta (Dynamics MVP)

For corporate training/ consulting, visit www.xrmforyou.com or write to us at info@xrmforyou.com

{Dynamics 365 Security Nuances} Can a user work with only team roles in Dynamics 365

Recently I was conducting a training in Dynamics 365 where I got the same question. Just a quick thought and the answer that comes to mind is “Yes”. After all,

a user’s security role is the sum of the security roles directly assigned to the user + sum of the roles the user derives through it’s association with the Teams (provided teams are given security role)

And here I was, where a user is belonging to a team and the team has a security with all the right privileges assigned to make the user work in Dynamics.

When I assigned the role directly to the user and the user is not part of the team, it just worked fine. Now comes the other way round. I remove the user’s security role, assign the same security role to a team and add the user to the team.

image

As you can see, the security role is having pretty much everything to access this account.

Login screen below after the user logged in.

image

 

Looks awesome isn’t it. The user can see accounts as expected. Just when you think that you have won the hearts of participants with your awesome understanding of Dynamics, Dynamics would throw a stick or two at you.

So I clicked on Account and this is what I get below.

image

That facepalm moment where you are just thinking, what just happened?

Now time for some recovery. When I click on Advanced find and try to access accounts, I could see them just fine.

image

 

You can even create/ read/ write and do all the fancy stuffs as per the role privilege.

Now I just did this trick. I just created a dummy role with absolutely no privilege to any entity and added it to the user. And this time when I click on Sales –> accounts, it just works fine.

 

So next time when you are up to this, this can save you some awkward moments. Not sure if this a bug or expected behavior but it seems the problem is only with the Home Page grid. Even if I try to read/ write accounts with the user credentials programmatically using SDK, it works fine.

For the home page grid to work, it requires a role to be assigned directly to the user.

 

Debajit Dutta (Dynamics MVP)

For training/ consulting, please write to us at info@xrmforyou.com or visit our website www.xrmforyou.com

{Dynamics 365 Quick Tip} Hiding Navigation Pane in forms exposed on Mobile (including Owner relationship)

Dynamics have evolved over the years and with time it has become a really vast tool. So many features are in there that we may not have used till now in all our projects. They are there though, sitting quietly and can do some pretty cool stuffs. But you remember them when you need them the most. Once such scenario, I am going to describe here.

So here I was working for a customer who wants to expose their CRM on mobile. We created separate forms for mobile, light-weight than the web versions and exposed them on mobile. However with the mobile real-estate being really less, customer wanted the navigation options to be hidden.

So it started, developers removed all the links in the navigation pane using form editor. And published the form.

Wouldn’t it be perfect. It should just work right. Sadly no. You may end up removing all but the nagging owner relationship (for user owned entities). And in mobile, it would just occupy the first tab.

image

Well, it won’t go, no matter how much hard you try, until you go to the Form Properties –> Display Tab –> Uncheck “Show Navigation”

image

Save and publish the form. And voila, it just works!

Hope this helps

 

Debajit Dutta (Dynamics MVP)

For training/ consulting please write to info@xmrforyou.com or visit us at www.xrmforyou.com

Error while configuring Field Security – The user does not have read permissions to a secured field.

Dynamics CRM never ceases to throw surprises to me and this even applies to the functionalities which were introduced way back in CRM 2011.

Recently in a session I was demoing field security and strangely one participant informed me that he is getting the below error while setting the field security profile for a user.

image

Cross checked whether he enabled field security for the field. And it was obvious he was doing with admin login. And strangely enough the error says “the user does have read permissions to the secured field”. Downloaded the error log but that didn’t help much as well.

image

 

This put me in a situation. Don’t know where to look into.

Suddenly I just published the entity again in frustration and after that when I tried, the error was gone. As it turned if you don’t publish the entity after enabling field security for a field and try to configure profile for the field, you get this error.

Publish is obvious but this kind of error message can throw you completely in a wrong direction.

Hope this tip may save you from some time and awkward moments.

 

-Debajit Dutta (Dynamics MVP)

For training/ consulting please visit www.xrmforyou.com or write to us at info@xrmforyou.com

{Dynamics 365 + Sharepoint} Sharepoint folder naming issue in CRM-Sharepoint OOB integration when Primary attribute is more than 128 characters

CRM-Sharepoint integration – This topic has certainly lost the steam by now and anybody working in dynamics over the last 7-8 years have tried it out so many times. Done and dusted topic, isn’t it?

But just when I think I know it all, Dynamics surprises me with some hidden nuances and my today’s post is on it.

So here I was, setting up the mundane CRM-Sharepoint OOB integration and directly set-it up in client’s production environment. OOB feature, no testing required. But suddenly one issue reported by customer – “My two records in account are sharing the same folder in Sharepoint”.

But how is that possible? A little bit of digging and this is what I found out.

In Dynamics CRM – Sharepoint integration, the folder gets formed in the format – Primary Attribute Field value_<Guid>. So if for an account record, it would be <account name>_<account guid>.

Now let’s play around with the Account Name.

This is below account name I have given for one record.

“the quick brown fox jumps over the lazy dog. the quick brown fox jumps over the lazy dog. the quick brown fox jumps over the lazy dog. the quick brown fox jumps over the lazy dog.”

Below is the name for other account record.

“the quick brown fox jumps over the lazy dog. the quick brown fox jumps over the lazy dog. the quick brown fox jumps over the lazy dog. lorem ipsum dolor sit amet.”. Notice the part in bold I have changed from the previous account.

 

Now, let’s go and see the folder created for the first account record.

image

There is no guid in the folder name. The reason is in OOB integration, folder name limit is always 128 characters. So if primary attribute name length is more than 128 characters, it would be trimmed to 128 characters and then the folder name is formed. So first lesson learnt, the Guid is not mandatory in the folder naming in Sharepoint for CRM-Sharepoint OOB integration.

Now it’s obvious that this is a potential root-case of problems. I also uploaded one document for this record and as you can see from the screenshot.

Lets go ahead and see the folder created for record 2.

image

 

As you can see from the above screenshot, the folder name for record 2 is also mapped to the folder for record 1. This is because the first 128 characters for both the account records are same. Hence the same folder got created. And as you can see, although I have not uploaded any file in record 2, still the file uploaded in record 1 is visible here.

This can be a potential problem.

Hope this helps!

 

Debajit Dutta

(Dynamics MVP)

For training/ consulting/ tools please visit our website www.xrmforyou.com or write to us at – info@xrmforyou.com

{Quick Fix} Qualify button on Lead not working in Dynamics 365

I have been working with Customer IT Team on a Dynamics 365 project and we have been doing kind of fancy stuffs, new features and what not. And suddenly we are being reported that Qualify button on lead form is not working. However the same is working from the “Home Page grid”.

First glance and I thought – Must be some silly tampering with the Qualify button. However one quick inspection with Ribbon Workbench negated that suspicion. How can such a stuff working for years can’t work all of a sudden in our environment? Product Bug? Can’t be for sure. It’s been working for years!

After beating around the bush, we finally decided to keep a back-up of our customizations and restored vanilla lead form from different environment. Qualify button started working like piece of cake.

In curiosity, to find out what caused the issue, I started removing one field after the other and finally found that the magic field was “Company Name” field. The moment I removed that, Qualify stops working.

Strange isn’t. But that’s how it works.

Honestly, Qualify button may not work for host of reasons but if you find yourself banging your head over this functionality, this article might just make your day!

Hope this helps

 

Debajit Dutta

(Dynamics MVP)

For training/ consulting please visit www.xrmforyou.com or write to us at info@xrmforyou.com

{Zero Code development} Putting images in Dynamics 365 view for encoding Case severity

Another fantastic article for Deepesh Somani

MSDYNAMICSBLOG BY DEEPESH

Business Requirement: Often there is requirement to show Case severity in some colour encoded way in Dynamics 365. For example, refer image below:

clip_image002

Solution: Below steps can be used to achieve this requirement without writing code:

1. Go to Settings->Customization->Entity->fields and add a new field of type Option Set. In the example above I have created a new field Case Severity on Case entity. Add items text from the following link: http://classic.getemoji.com/

Following images were used in the above example:

clip_image004

clip_image006

2. Add the column as the first field in Active Case view and other views that you wish. Optionally, you can also place the field on the Case entity form. Next, in the editable grid you will be able to set the priority by this field:

clip_image008

3. Not only that, you will be able to group as well by selecting Group by:

clip_image010

Hope it helps and Happy CRMing.

Any…

View original post 43 more words

{Dynamics Version 9.0} Execute custom action with all parameter types in Dynamics CRM Version 9.0

Dynamics Version 9.0 introduced the Xrm.WebApi namespace which provides all the methods to interact with dynamics CRM server from client side script.

Detailed Documentation – https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/clientapi/reference/xrm-webapi

However recently I was working on a project to upgrade the SOAP calls from client and replace them with the new Xrm.WebApi methods. Create/ delete/ update were kind of easy and was easily ported to the new API’s.

However then came the Actions. The client had actions which had many input parameters and which were getting invoked from the client using SOAP calls. We had to port them to the Xrm.WebApi. But in Xrm.WebApi we did not had any function like executeAction. But the Xrm.WebApi.execute came to our rescue.

Let’s first examine Xrm.WebApi.execute method. Microsoft documentation shows it like this –

Xrm.WebApi.execute(request).then(successCallback, errorCallback);

For the sake of brevity of this blog post, I am skipping the documentation of the parameters. For detailed information on the parameters, please refer the below Microsoft documentation link – https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/clientapi/reference/xrm-webapi/execute

 

So how to call an action with input parameters? For this post, I created an action named “new_TestAction”. The action is global. It has the following input parameters.

  • Name – Type (string)
  • Age – Type(string)
  • InputEntityReference – Type (EntityReference)
  • InputEntity – Type (Entity)
  • InputEntityCollection – Type(EntityCollection)

For entityreference, entitycollection and entity, I have kept the Entity as Account Entity. All set and done. Now the next step is to call the action. below is the sample code to create the request object. All the important parameters has been highlighted and appropriate comments put.

TestAction1: function (input1, input2, inputEntityReference, inputAccount, inputAccountCollection) {
        this.InputEntityReference = inputEntityReference;
        this.Input1 = input1;
        this.Input2 = input2;
        this.InputEntity = inputAccount;

        this.InputEntityCollection = inputAccountCollection;

        this.getMetadata = function () {
            return {
                boundParamter: null, // for entity action, put the entitysetname/ entitylogicalname here
                parameterTypes: {
                    "Input1": {
                        "typeName": "Edm.String",
                        "structuralProperty": 1 // Primitive Type
                    },
                    "Input2": {
                        "typeName": "Edm.String",
                        "structuralProperty": 1 // Primitive Type
                    },
                    "InputEntityReference": { // Entity Reference
                        "typeName": "mscrm.account",
                        "structuralProperty": 5
                    },
                    "InputEntity": { // entity
                        "typeName": "mscrm.account",
                        "structuralProperty": 5
                    },
                    "InputEntityCollection": { // entity collection
                        "typeName": "mscrm.account",
                        "structuralProperty":4 // collection type
                    }
                },
                operationType: 0, // 0 for action, 1 for function and 2 for CRUD
                operationName: "new_TestAction1"
            };
        };
    }

Next is the code to create this request object and pass the object to the action.

ExecuteAction: function () {
        debugger;
        var accountReference = {
            "@odata.type": "Microsoft.Dynamics.CRM.account",
            "@account.id": "9602CEB2-55F7-E711-A954-000D3A34A0AA"
        };
        var accountEntity = {
            "@odata.type": "Microsoft.Dynamics.CRM.account",
            "@account.id": "9602CEB2-55F7-E711-A954-000D3A34A0AA"
        };
        var accountEntityCollection =[
            {
            "@odata.type": "Microsoft.Dynamics.CRM.account",
            "@account.id": "9602CEB2-55F7-E711-A954-000D3A34A0AA",
            "name": "Test Account 1"
            },
            {
            "@odata.type": "Microsoft.Dynamics.CRM.account",
            "@account.id": "9602CEB2-55F7-E711-A954-000D3A34A0AA",
            "name": "Test Account 1"
            }];
        var requestObject = new TestAction1("Name", "Age", accountReference, accountEntity, accountEntityCollection);
        Xrm.WebApi.execute(requestObject).then(function (result) {
            debugger;
        },
        function (error) {
            debugger;
            console.log(error.message);
        });
    }

Simple isn’t it. I haven’t covered the other primitive types like – Decimal/ Int. They are pretty simple like for int, it is Edm.Int32.

Hope this helps!

 

-Debajit Dutta

(Dynamics MVP)

For consultation/ training visit www.xrmforyou.com or reach out to us at info@xrmforyou.com

 

 

Understanding SharePoint Document Locations for Entity based folder structure–Dynamics CRM + SharePoint integration

Recently I was handling a training in Dynamics where I was demoing the OOB CRM SharePoint integration.

Client was already using the OOB CRM-SharePoint configuration using entity based folder structure. Anyone getting confused what is meant by entity based folder structure? Well while configuring you get an option to select whether based on Account/ Contact.

I selected Account here. Not a big deal.

image

But here it gets interesting. What if I upload some documents for a child record of an account and then change the account for that child record?

To duplicate this, I followed the below steps

  • Created two accounts – Account A & Account B
  • Created a case – Case | Document Test for Account A
  • In the Documents Section, uploaded file named – Document 1.txt

Let’ see the folder structure in SharePoint after this operation.

image

No surprises here. As we have chosen Entity based folder structure, the document got uploaded for the case under the account for which the case has been logged.

Now let’s go ahead and changed the account of the case to Account B

image

Now if we go ahead an upload a Document for the case – Document 2.txt, it should roll up under Account B. Let’s see that if it happens.

I go ahead and upload the document. But surprisingly it is still uploading under Account A in SharePoint.

image

 

Strange isn’t it? But why it happens? To understand this we need to understand the Document Locations record that CRM uses to map to the corresponding folder in SharePoint.

The following are the document locations record that got created after we uploaded Document 1.txt.

image

As you can see, four document location records got created

  • One for entity – account
  • One for account record – Account A
  • One for entity – (case)incident
  • One for case record – Case| Document Test

As you can see all are named “Document on Default Site 1”. This is confusing. So let’s name it accordingly.

Below is the screenshot after renaming. Probably looks simpler now with the names.

image

Looks go ahead and create the document location record manually for Account B.

image

 

image

 

image

 

If you now come back to the Case record and move to the Documents section, you will find two document locations now but if you select the Account B Document Location record, you will find no upload button.

image

This is because the corresponding folder in SharePoint does not exist. Lets go and create that.

image

 

Now if you go ahead to the case and move to the Documents section, you would find both the Document Locations for previous and current account.

And if you now upload a document to the case for the current account, it goes and sits at the right place. And you can always switch back to see what were the documents uploaded for the previous account as well.

image

Hope this helps!

 

Debajit Dutta

(Dynamics MVP)

For training/ consulting/ tools, please visit www.xrmforyou.com

Documents Link missing in Navigation pane even after enabling Document Management in Dynamics Version 9.0

Recently I was in a training for a client where I was demoing the CRM – SharePoint  OOB integration. So I enabled the integration and then also enabled the Account Entity for Document Management.

However when I opened a Contact and tried to Navigate to the Documents section, I find no link in the Navigation Pane. Looked like the one below.

image

Bit embarrassing since just before that I told the participants that the document link would appear once I enabled the entity for Document Management.

Bit flummoxed, I checked for the relationship whether mistakenly I have made the relationship display to False. It was not the case.

Then jumped on to the form editor and clicked on the Navigation Pane and then much to my relief, I could see the Documents tab in the available relationships.

image

 

Just dragged the relationship on to the Common relationship area. Save and publish the customizations. And much to my relief I could see the Documents link in the Navigation Pane

image

 

Small thing. But saves you some moments if you know this.

 

Debajit Dutta

(Dynamics MVP)

For consulting/ tools/ training please write to us at info@xrmforyou.com or visit our website www.xrmforyou.com