Understanding Security in Dynamics 365 CRM Apps

Dynamics 365 CRM apps provide several ways to control access throughout your system. Three of the primary tools are Business Units, Security Roles, and Field-Level Security. Each serves a different purpose:

• Business Units can separate data between different parts of an organization.
• Security Roles control what users can see and do, primarily at the table and record level.
• Field-Level Security can restrict access to individual fields.

Together, these tools allow organizations to build a highly customized security model around their users and business processes.

Using Business Units to Separate Data

Business Units can be useful when an organization contains multiple businesses or divisions that need different levels of access to CRM data. For example, if your organization acquires a sister company, you could create separate Business Units for the original company and the acquired company. Security roles can then be assigned based on those Business Units to control which data each group can access. Business Units can also have their own security roles. When configuring security roles, access can be provided at several levels:

• None
• User
• Business Unit
• Parent-Child Business Unit
• Organization

This gives you flexibility in deciding how much information should be shared across your organization. For example, two Business Units might share Accounts and Contacts using organization-level access while keeping Leads and Opportunities separated through Business Unit-level access. Business Units aren't necessary for every organization, but they can provide valuable data separation without requiring completely separate CRM environments.

Understanding Business Unit Modernization

Business Unit modernization expands the flexibility available when working with Business Units. An "Owning Business Unit" column can be added to tables, allowing you to select which Business Unit a record belongs to. This provides additional control over record ownership and data access within organizations that use a Business Unit-based security structure.

Controlling Access with Security Roles

Security Roles are one of the most important tools for managing security in Dynamics 365 CRM apps. They primarily control privileges at the table and record level, but they can also provide miscellaneous privileges for other functionality. For example, a security role might determine whether a user is allowed to import data. Standard roles can provide different levels of access depending on a person's responsibilities. Sales Team Members, Salespeople, and Sales Managers, for example, may require different privileges within the same CRM environment. Security Roles can determine whether users have privileges such as:

• Create
• Read
• Write
• Delete
• Append
• Append To
• Assign
• Share

These privileges can then be combined with different access levels to determine how broadly the user can perform those actions.

Follow the Least Privilege Approach

A good practice when planning CRM security is to follow the principle of least privilege. Users should receive only the access they need to perform their jobs and nothing more. If someone temporarily requires additional access, it can be provided when needed and removed afterward. This approach can reduce the risk of mistakes caused by users having more access than necessary. The same principle is particularly important for administrative permissions. Only a limited number of people should have administrator-level privileges because those permissions provide significant control over the CRM environment.

Layer Multiple Security Roles

Users can have more than one Security Role at the same time. This lets you create roles around different responsibilities and combine them as necessary. When assigned roles provide different levels of access, the user's resulting permissions reflect the greater level of privilege. Because roles are additive, assigning an additional role can increase a user's access rather than restricting permissions provided by another role. This is important to remember when troubleshooting unexpected access.

Use Check Access to Troubleshoot Permissions

Dynamics 365 includes a Check Access feature that can help explain why a user can or cannot interact with a particular record. Users can review their own access and assigned roles. Administrators can also investigate the access of other users. If someone discovers that they cannot perform an expected action, Check Access can help identify whether their current security configuration is responsible. The user can then determine whether additional access should be requested.

Assign Security Through Users or Teams

Security can be assigned to individual users or through teams. Using teams can be helpful when multiple people require the same access. Individual assignments may be more appropriate when permissions are specific to a particular person. When designing or revising a CRM security model, consider creating roles around job responsibilities. This role-based approach can make permissions easier to understand and maintain as the organization grows. Dynamics 365 security is highly customizable, and your security model can continue to evolve after the initial implementation.

Customize Existing Security Roles

You don't always have to create a Security Role entirely from scratch. An existing role can be copied and modified to better reflect your organization's requirements. This can provide a useful starting point when the standard roles offer most, but not all, of the permissions needed for a particular job function. As with other aspects of Dynamics 365, Security Roles can be adjusted over time as your processes and access requirements change.

Protect Individual Fields with Field-Level Security

Sometimes access needs to be more granular than an entire table or record. Field-Level Security allows organizations to control access to particular fields. For example, you might have a field that most people should be able to see but only certain users should be allowed to change. Field-Level Security can be used with both standard Dynamics 365 fields and custom fields. To use it, column security must first be enabled for the appropriate field. Security profiles can then determine which users or teams have the appropriate access. This provides another layer of control when sensitive or important information requires tighter restrictions than the rest of the record.

Use Auditing to Monitor Important Changes

Auditing provides another useful piece of a CRM security strategy. Dynamics 365 auditing can help organizations track activity and determine who made particular changes. This can be especially valuable when an important record or piece of information is changed or deleted. If an issue occurs, auditing can help you understand what happened. You can then decide whether changes should be made to a user's Security Role or other permissions to reduce the chance of the issue occurring again.

Build a Comprehensive CRM Security Plan

Business Units, Security Roles, and Field-Level Security provide different layers of control within Dynamics 365 CRM apps. A thoughtful security model can use these tools together to determine:

• Which areas of CRM users can access
• Which records they can view or modify
• Whether data should be shared across Business Units
• Which individual fields require additional restrictions
• Which users need elevated or administrator privileges

Your security configuration doesn't have to remain static. It can be refined as your organization learns more about how employees use the system and what access they need. The key is to begin with a comprehensive security plan and follow the principle of least privilege. Give users the access required to perform their responsibilities, provide additional permissions when there is a legitimate need, and keep administrative access limited. This gives your organization granular control over Dynamics 365 while helping maintain a more secure CRM environment.