5 tips for managing security roles in Microsoft Dynamics 365

Security management is extremely important due to legislation such as GDPR and the rise of cybercrime. Every CRM administrator is expected to do the necessary in terms of data security. From our experience, we give 5 tips to CRM administrators for a logical and maintenance-friendly management of security roles in Microsoft Dynamics 365.

In this article we assume that the reader has the necessary knowledge of the security model of Microsoft Dynamics 365. The complete documentation on security management in Dynamics 365 can be viewed at the following Microsoft website ➡️ docs.microsoft.com/en -us/dynamics365/customer-engagement/admin/manage-security-users-and-teams

TIP #1. “Teams” are more flexible than “Business Units”

“Business Units” are very effective for shielding data between different departments of your organization. But think carefully before using Business Units, because this creates a less flexible security structure.

Does it sometimes happen that an employee from a certain department works temporarily with colleagues from another department? Then it is better to organize your users in “Teams”. “Teams” give the flexibility to temporarily add a CRM user as a member of a Team. Each user who is in that Team automatically inherits the user rights from the Team. When the temporary intervention of the helpful colleague has ended, you remove him/her as a user from the Team again.

TIP #2. Do not replicate the organizational structure with “Business Units” in CRM

Contrary to what you might expect, your organizational structure rarely aligns one-to-one with the Business Unit structure appropriate for your CRM organization. How so? It is often the case that different departments work together on the same data. This is the case if an operating process runs through multiple departments in your organization.

Business Units should rather be seen as a way to create logical dividers in your CRM database.A useful application of Business Units is to separate data between groups of employees who do not work together on the same data. For example, if you want to keep data about sales opportunities separate per country or region.

TIP #3. A hierarchical set of security roles simplifies management

In Dynamics 365 you can associate multiple security roles with one user, with the most permissive security role winning. For example, if you combine a security role with permissions to see only your own contacts with a security role that gives you permissions to see all contacts, the result is that you see all contacts.

This allows you to access the security roles in your organization in a hierarchical way. You can create a “Basic Role” with the rights that every CRM user must have. You can then create an additional security role for each “responsibility” in the work organization, where you bundle the extra functional options that are required for that person to perform his function. For example: a Basic Role + a Sales Employee Role.

Typically, management in an organization is given additional security rights in Dynamics 365. This person, who heads a team, needs an clear view and/or extra security to view the management reporting. For example, a Sales Manager gets 3 cumulative security roles: Basic Role + Sales Employee Role + Sales Manager Role.

With such a hierarchical system, the maintenance of the security of the CRM users is a lot easier because the security rights are logically grouped. In this case, a security role corresponds to the responsibility that someone has. This way, as a CRM administrator, you avoid having to set the same rights multiple times in multiple roles.

If a new employee starts or if someone changes position, it is easy for the CRM administrator to adjust the corresponding security roles. Even if a new functionality is added in the CRM application, the CRM administrator can make the new functionality easily accessible by giving additional rights to the security role that corresponds to the job profile of those employees. For example, if an extra module is added in CRM for Sales, you add the necessary rights to the sales roles. Will there be new functionality in CRM that everyone will have to work with? Then you just add the additional rights to the Basic Role.

TIP #4. Be careful with delete permissions

In general, we apply the principle that it is not the intention that CRM users can delete data. Because you still want to be able to report on all data in CRM. The big problem with Delete permissions is that deleting records can happen accidentally. In that case, a ‘disaster recovery’ has to be done and that is difficult and time-consuming.

The alternative to “Delete” is “Deactivate”. This ensures that you, as a user, are no longer confronted with the deactivated record, because deactivated records are not shown in display lists. If necessary, you can still look up this record, because it has not really disappeared.

In exceptional cases, you could give users the rights to delete records that they have created themselves. We also recommend centralizing Delete rights with one or a few people who are well aware of the technical consequences of deleting CRM data.

TIP #5. Sharing isn’t always caring

An employee may need to work on one particular record for which the CRM user does not have access rights. In that case you can “Share” that one particular record. Our advice is therefore to limit “Sharing” of records, because every set “Sharing” is an extra filter that your CRM system must take into account with every data manipulation and retrieval. If you systematically use Sharing, this will weigh on the performance of your CRM system over time. So: Share, but handle with care.