Gotcha: Don’t Use Nested Security Group

Some time ago, I published a blog post about a tip about using Security Group in Dynamics 365 Online Deployment. And I’ve got a feedback from one of my colleagues where the security group is not allocating the users properly. So, I investigated the behaviour with my colleague and found an interesting setup.

TL;DR; version: Do not use Nested Security Group, as Dynamics 365 would not honour it.

The Long Version

So, I noticed in my colleague’s environment they have set up nested security group. To explain, I’m going to “replicate” the scenario in my environment.

I have set up my sandbox environment to use “Dynamics Sandbox” security group as follow:

And the Dynamics Sandbox security group has membership as below:

“Dynamics Test” there is the child group that I have setup with the following members:

Normally, When I have a nested group like that. I would expect Test User 2 – 5 will also be included in the Enabled Users list. However, this is the result:

To ensure the rest of the users are synced to Dynamics 365 the group must be flattened:

Then, you’ll be able to see them in Dynamics 365.

I have confirmed the behaviour with the Microsoft support, that nested group is not supported at this moment.

Hope this helps!

Leave a comment