Dynamics 365 Security: context, context, context!


Have I mentioned how important the context is?

Whenever you address a security question in Dynamics 365 Customer Engagement, there are always two contexts that you must take into consideration: the data context and the user context.

The data context: it is provided by the record’s owner but also (and it’s very important), by the Business Unit of its owner (whether it is a user or a team).

The user context: his or her Business Unit as well as his or her different security roles. Whether those roles are assigned directly to the user, or to the teams he or she belongs to. The respective context (especially Business Unit) of these various roles is crucial.

How should you configure your user rights?

There are several ways, but you mainly have two options to configure the rights of users in Dynamics 365:
  • With security roles that are directly assigned to them.
    …and that apply in the context of the user’s Business Unit. 
  • With security roles that are assigned to teams they belong to.
    …and that apply in the context of the team’s Business Unit. 
It is of course possible (and sometimes necessary) to mix and match the two options, with both roles that are directly assigned to the user and others that are assigned to teams he or she belongs to:


How to know the context of a security role?

Well, that’s an easy one: it’s written on it when you assign it!

A security role’s access level is only defined by the context of the user or team to which it is assigned:


Why should you assign at least one security role directly to a user instead of relying solely on team-based security?

It is recommended that even with a security model based on roles that are assigned to teams, users should have at least one security role directly assigned to them. It is mandatory if you want your users to be able to access personal CRM options, formats, languages, or have default forms, personal views, personal charts and personal dashboards (because they would need to be the owner of them, as it can’t be a team).


You should also know that if you want users to be owner of records that only them should see, a security role containing a “read” privilege with a “user” access level, assigned to a team the user belongs to would not work. That would mean that the team can be the owner of the record, not the user belonging to the team.

Yes, security roles are additive… but be careful, they are additive in their respective context!

Security roles apply exclusively in the context of the user or team they are assigned to (and so in the context of the Business Unit of the user or team)

Example:


It is a misconception to think that because a user is part of a team, they can benefit from the team’s security role in their own user context. In fact, they benefit from each security role, but in their respective contexts.



Comments