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

The behavior explained in this blog has changed a little with introduction of new Azure AD Group teams in Dynamics 365 April 2019 release. To know more about it, click here.

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.


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

Login screen below after the user logged in.



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.


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.



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.


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


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.


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.



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.


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.



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