This is the next post in a series covering my revision for the MB2-712 certification. (Microsoft Dynamics CRM 2016 Customization and Configuration) In this post I will introduce the Dynamics CRM security model.
If you are an experience CRM user, hopefully the concepts here are very common to you. But a quick bit of revision never hurt anyone! J
The security area of settings in Microsoft Dynamics CRM gives you access to most of the options needed to manage users, roles, field security etc. Use these options to configure how users interact with CRM and allow or deny them access to data.
- Users, allows you to manage users and associate them with business units / teams / roles and assign licenses.
- Teams, this option lets you define teams and also associate with security roles.
- Security Roles,
security roles let you define what access will be provided to teams and users. Roles are created and then one or more are associated with each user / team. - Business Units are a fundamental building block in the Dynamics security model. They define the structure of the organisation.
- Field Security
Profiles are used when you need to define specific access rights on individual fields. - Hierarchy Security, supports a security model based on someone’s hierarchy. Which can either relate to the manager they have defined in their user or positions.
- Positions, define organisational positions which support the hierarchy security model.
- Access Team Templates, support dynamic record sharing. With the members of an access team being given privileges on specific records based on the access team template.
Business Units
The first option to consider is business units, this allows you to define the structure of your organisation. Users, teams and security roles will be linked to business units making them a fundamental building block in the security model.
Below you can see that I have created an example business unit. All of my international sales team will be linked to this business unit. (I wish!) Notice that most of the fields about address (etc) have been left blank. These extra fields are not essential and are really just for reference in the application, meaning they have no function with the security model.
Some points about business units you will need to know;
- The root business can be renamed.
- The root business unit cannot be deleted or disabled.
- The root business unit cannot be moved to have a parent business unit.
- The name of the root business unit will default to the organisation name when the system is first deployed.
- All child business units have a parent which will either be another child or the root business unit. Meaning the root business unit is always the top of the business unit hierarchy.
- The parent business unit on a new business unit will always default to the root but can be changed.
- The definition of business units often follows the companies organisational structure but this is not essential. Ideally the business unit structure should mirror whatever is needed to support the security requirements of an organisation.
- Child business units can be renamed.
- Child business units can be disabled.
- Child business units can be delete but only after being disabled.
- Any users in a business unit will lose access to the application if the business unit they are assigned to is disabled.
- Child business units can be moved under a new parent – If you move the business unit users will move with the business unit.
Tip: In past exams I have often seen questions around what can and can’t be done with root and child business units. Make sure you know this stuff!
Users
Firstly users will need to be created an authenticated. In an on premise architecture this will mean the user must exist within Active Directory and with online they must exist as a user with Office 365.
Note: If you sync your local active directory with your Azure active directory, it is possible to sign into CRM online using a local AD account.
Once the user is signed in, either via Office 365 or AD, then the CRM security model is used to control what they can access.
When creating a user in CRM (on premise) we use the “Users” option found in the security area. The user name is the domain name and user name from active directory.
With Office365 the process is a little different. As you will need to assign a CRM license in the Office 365 admin area. Below you can see that I have created a user called Poppy and assigned a CRM license in Office 365. Following this process in Office 365 will create the user record in CRM but I will then need to use manage roles in CRM before Poppy would be granted access.
When creating users, the business unit is a mandatory field and will default to the root business unit. To access CRM a user must also be given at least one security role.
With on premise an option exists to add multiple users. Having selected the option “NEW MULTIPLE USERS” you will be prompted for a business unit and the role(s) to assign. As all the new users will need to be added to the same business unit and have the same roles. You will then be asked to confirm some details such a license type.
Finally, you can select the users you wish to add from Active Directory. This approach is very useful when adding a large number of new users, you just need to keep in mind that all the users created will have the same business unit and role(s). So you may need to run the option multiple times if a structure of business units exists.
You cannot delete users. You can however disable them. With on premise you can simply disable the user within the Users area of CRM. With online you need to open the user in Office 365 admin and remove their license.
If you change a user’s business unit that can be done with the change business unit option. If the user owns a lot of record in CRM this process can take a long time! If you move a user from one business unit to another their security roles will be removed. So having completed the move new security roles will need to be added before they can access CRM again.
Roles
I will discuss how to create roles and how they operate in a future post. At this point it will enough to understand that each user can have one or more roles. And that you use the MANAGER ROLES option on the user’s record in CRM to do this.
One thing that is worth mentioning at this point is that the roles suggested will be ones appropriate for the business unit the user resides in. As I have said I will cover roles in greater detail later. But one concept worth mentioning here is that some roles will be inherited from the parent business unit. So even though I haven’t created any roles specific to the International Sales Department I still see all of the out of the box roles defined on its parent. (In this case the root business unit.)
I hope this post has given you an overview of the security options available in CRM 2016 and described business units in a little more detail. I will build on this information as I continue my revision for MB2-712.
J
NEIL PARKHURST 
Leave a comment