Dynamics 365 User Security

Setting up security in your Dynamics CRM data may involve crucial decisions that can strongly affect the success of your system.  Our focus today will be on a high-level overview of some options that you have to hide and show records for individual users.  We will not cover functional security, which indicates what permissions a user has regarding records; we will only cover record-level security (whether a user can see a record or not).  This article will focus on accounts but applies to most other entities in the system.

Security in Dynamics CRM revolves around a built-in field called the Owner.  You will notice this field available in most entities and can be set to either a user or a team.  The Owner field is a required field, so each record must be “owned” by a single user or team.  You cannot set the Owner field to more than one user or team.

All record level security is “additive” in Dynamics CRM.  This means that you can apply multiple security levels or types to a single user or record, and the user always gets the highest-level permissions possible.

You are not able to “deny” permissions to a user.  This means that if you use security roles to give a user “organization” level permissions to accounts, this gives the user permission to see every single account record in the system.  You cannot then remove the ability for that user to see certain accounts since the user already has access to see everything; the user will always see all accounts in the system.  To summarize, you cannot “deny” access to an account; you can only “grant” access to an account.

There are three ways to provide access to accounts if a user doesn’t already have the appropriate permission:

1. Security Roles
   These make up the core security in Dynamics CRM. Users must be assigned a security role to log in to the system, because without a security role they will have access to absolutely nothing (including the ability to log in!)  Users may be granted more than one security role.  Remember that security is additive, so if you apply more than one security role to a user, the user gets the highest permissions possible when combining all their roles.  It is not possible to “deny” a user permission using security roles.
2. Sharing
   This is a way to grant permission to an individual account record for an individual user. If a user doesn’t normally have permission to view an account, then another user can “share” that account with the person who needs permission to it.  This is a good way to allow users to see accounts on a one-by-one basis.  Be careful when using the sharing feature, because there is no way to find out which records have been shared with which users, so security can get out of hand quickly if users do a lot of sharing.  When sharing you may specify, on a user-by-user basis, what each user can do with that account as well (e.g., read, write, delete, etc.) You may share a record with users and/or teams.  Sharing is performed by clicking on a button in the command bar which brings up a new window.  It is not possible to “deny” a user or team permission using Sharing.
3. Access Teams
   This is similar to Sharing as it allows a user to specify which other users may access an account. The difference between Access Teams and Sharing is that with Access Teams you cannot specify what permissions an individual user has when they get access to the account (e.g., read, write, delete, etc.) as all users will share the same pre-defined permissions.  Rather than having to work with a separate pop-up window, as with Sharing, Access Teams can be set directly from the data entry form of the Account, which makes it much more convenient.  You can also perform searches on Access Teams within the Advanced Find feature to find out which users have been manually granted access to accounts.  It is not possible to “deny” a user permission using Access Teams.

As I mentioned at the start, this is only a very high-level overview of security in Dynamics CRM.  In fact, security is significantly more complex than what I touched on here and can get out of hand very quickly if you aren’t careful.  Contact TopLine Results to review your security requirements, and we will determine the best way to utilize the tools available to achieve your goals.

About the Author
Dan Boehm is our senior developer and lead engineer for CRM implementation projects. With more than ten years of Microsoft .NET and CRM experience, Dan specializes in complex CRM development and migration projects with an emphasis on creative solutions which meet and surpass client expectations.