By Robin Schaareman
Within Dynamics 365 a layered security model, strengthened by a Base security role, will give you and your customer maximum flexibility in configuring the system and meet the customer needs.
In this article I will try to explain from my own experience what I found valuable in designing a security model.
Start early in the process
When on a “green field” project don’t hesitate to start talking about the security model at an early stage. Some customers demand special requests that certain users/teams don’t have any access to particular data from another country for example.
When working on a global rollout or a regional one can influence your decisions in designing the model. In some countries opportunities is one of the entities that contains really sensitive data and it is particularly at risk when an employee decides to stop working for that customer. In other countries this is not an issue at all and both situations require a different approach in your security model. Some other really helpful questions that can help in designing a good security model:
- Will the records be user or team owned?
It can be handy to know who is owning a record… By default CRM will put the user as the owner of the record. Most of the time this is correct but, in some situations, this is rather odd. Let’s take an account for example, why is this owned by 1 person? In bigger companies which sell different products/services it is quite normal that an account can be owned by multiple people. In this case maybe a team as the owner will be a better option. Also, a totally different approach can be done via a new entity called employee’s involved, here can be a list of employees that are involved at that customer. The owner field can be hidden in that case. All of these questions/answers can impact your security role/model. - Can notes be visible to anyone?
Notes are attached to records but the security is not inherited, this means that the security of the notes entity need to be setup separate. - Activity type entities?
These type of entities are being managed via 1 security setup. If you can see all the activities of the whole organization this means that Tasks, Emails, Appointments, etc will be visible. It is good to talk about this upfront so there will be no surprises afterwards.
Base security role benefits
Most of us know that configuring a security role can be sensitive to “human” errors. This all has to do with all the dots you can click, or even the whole row. This and the fact that multiple roles sometimes need the same change is rather inefficient. The Base security role can simplify your security model. Give everyone in your organization a security role (name it the Base role for example) that will just give user the ability to login into Dynamics 365.
After that the role can be used to give users permissions to entities where the rules applies to all users. For example, if anyone in the organization can Read all accounts you can configure this in the base role instead of in all other roles. The change is much faster and easier to maintain. Do this for all the entities that users share privileges of. After this you can specify certain roles within the organization by just a few dots/clicks on a separate security role.
Extra dimensions
In Dynamics 365 a security role “dot” can be on User/Team, Business Unit, Parent/child Business Unit and Organization. The Business unit privilege can give a user different permission if you setup a different BU/Team structure. With a rather different structure you can create a new “dimension” to give users privileges and be more flexible in order to meet your customer needs.
Below are two examples. Let’s say we need to add a 4th team that need access to the opportunities of Team 3 and 4 only (so not Team 1 and 2). You can put the users in both teams and leave the user/team privileges on the role. But you can also add another layer to the Business units and give the role a BU privilege on opportunity. In this case Team 3 and 4 will be separate from the other teams. This extra dimension is a way to solve those requirements other than adding users to multiple teams constantly.
Don’t mirror the real world
The last tip I want to give is “Don’t mirror the real world”. Yes sometimes users refer to their team or department etcetera but this does not mean you need to build this situation in the system as well. This can make things much more complicated then it should be and sometimes you need to give up some of the flexibility as well.
