A hugely important part of any CRM system is determining who can use which elements of it, and more crucially who can interact with which records.

Luckily, Dynamics 365 has an out-the-box security model that helps you remain in control of the different levels of access across your business.
The model might seem a little complex on first glance, so, as your trusted advisors, we’ve created a simplified graphic (below) to help you understand the different elements that hold it all together – if you need help implementing something like for your system, please use the Contact form to get in touch with us!

Security in CRM Explained

There are five ‘pillars’ to implementing a security model in Dynamics:

  • Business Units (BU): These can be thought of as individual divisions or departments. They act as the building blocks of your security and define a boundary which is built upon by the security roles and access privileges that you implement. You can have multiple business units, and can build them in a parent:child structure to represent your hierarchy.
    An example could be a ‘Sales Team’, ‘Finance Team’ etc, or else make them location-specific one like ‘United Kingdom’ with child units for each regional office like ‘London’.
  • Users: These are people who have access to your system – these are always related to one business unit.
  • Security Roles: These are groups of permissions which define what users can and can’t do in your system – we generally build a “Standard User” and “Super User” role to give different layers of access, usually based on seniority or job role. Additionally, we sometimes apply function-specific roles, too, to give permissions to do certain things like edit products, view audit history etc.
  • Privileges and Access: These define the actions that users can perform in the system and the level/extent to which they have access to perform those actions. For example, can they create, edit, delete and share records only owned by themselves, can they also perform some (or all) of these actions on records owned by other members of the same business unit, or across the whole organisation?
    In the below example of security roles we have only listed three privileges, but the full list is:

    • CREATE, READ (view)
    • WRITE (edit)
    • DELETE
    • APPEND (be linked to another record eg. to say that an opportunity is for a specific account)
    • APPEND TO (link to another record eg. to allow the account to be linked to the above opportunity )
    • ASSIGN (change ownership)
    • SHARE

The visual below pulls this all together to show how all of these elements relate to one another, and then an example security model.

A visual flowchart showing the different security roles for Dynamics 365, and how they relate to business units and child business units.

Access Flows Downwards

So, in the model shown above, the Edinburgh business unit would, if combined with a security role providing parent:child BU access to the relevant records, provide the access to all the records within Edinburgh, plus in the London, Edinburgh and Cardiff (child) business units.

It does not give London and Edinburgh users access to interact with records in the business unit above them (Head Office) even if they had been given a parent:child business unit level of access in one of their security roles.

If there were child units underneath London, though, the users in London would be able to access relevant records in those business units if given the correct security role.

How about some examples?

1. Let’s consider a Salesperson – we’ll call her Kate – who works in London.

Kate has been given the Salesperson security role only – (from the image above).

This means she can view Accounts and Contacts owned by users in her own business unit, and by those in Edinburgh and Cardiff.

However, she can only edit Accounts and Contacts from the London office, and has even less permission to delete them – she can only delete records owned by her.

As she is a salesperson, she needs to be able to interact with Order records, to see what Orders her pre-sales work has generated, but the business does not want her to be able to snoop on sales orders taken by salespeople in Edinburgh and Cardiff, so she has been restricted to only viewing London orders.

She also cannot edit or delete Order records at all.

2. Now let’s consider Taylor, who is a Marketing Exec in the Head Office – because the head office is the parent business unit, this unlocks some of the ‘parent:child’ abilities provided by the relevant security role.

For example, Taylor will able to view, edit and delete Lead records owned by users in the Head Office, and in the London, Edinburgh and Cardiff offices.

He can also, like Kate, view all accounts and contacts in the organisation, Unlike Kate, he has no ability to edit or delete accounts and can only delete Contacts he owns.

This evidences that, despite Taylor working at the Head Office which is the top of the tree, his given security role (and the access levels contain therein) still drives what he is able to access and he has fewer permissions than Kate for some record types.

In Summary

We hope this gives you a good insight into how to structure your security, and how closely you can restrict / open up access to types of records in your CRM system.

Getting this right from the beginning of a system build is much easier than trying to engineer it across an established system, but realistically if you plan correctly you can implement it at any stage to fit with your business’s changing needs.

As always, we recommend getting your relevant teams and/or premises on board and involved in the design of this model, both so that they understand it from the get go and so that employees will not push back against potentially having their read / write / create / delete access restricted.

Need help? Give us a call and we’ll get you set up with the right security roles for your business.