Microsoft Dynamics 365 CE Security
Security
Dynamics 365 CE Security
Dynamics 365 CRM
Jun 2, 2025
D365 Customer Engagement (CE) Security Introduction
Security in Dynamics 365 Customer Engagement (CE) is a foundational aspect of any implementation. It governs how data is accessed, who can perform which actions, and how organizations maintain compliance, confidentiality, and control over business-critical information.
Whether you're building a CRM system for a small team or deploying Dynamics 365 across multiple countries and departments, having a solid understanding of the platform’s security model is crucial. It ensures that users see only what they need, administrators can manage permissions effectively, and data integrity is maintained at all times.
In this article, we'll explore the key components of the Dynamics 365 CE security model, including Business Units, Security Roles, Teams, and advanced mechanisms like Field Security and Hierarchical Access. We'll also share best practices and real-world scenarios to help you design a secure and scalable solution.
Core Components of the Security Model
Dynamics 365 CE uses a layered security model that combines organizational structure, user roles, and record-level permissions to control access. Understanding how these layers interact is essential for designing a secure and efficient CRM system.
The core components include:
Business Units – define the organizational boundaries for data access.
Security Roles – determine what users can do with the data.
Teams – provide flexibility in access management across units.
Field-Level Security – restrict visibility to sensitive fields.
Record Sharing – allows fine-grained access on a per-record basis.
Each of these elements contributes to the overall security posture and enables organizations to implement both standard and complex access control scenarios. Let's break down each component.
Business Units
Business Units (BUs) are the foundation of the Dynamics 365 CE security model. They define how data is partitioned across the organization and control the scope of access for users.
Each user, team, and record is associated with a single BU. The BU hierarchy starts with a Root BU and can include multiple child levels to reflect organizational structure - such as departments, regions, or brands.
Security roles respect this hierarchy by allowing privileges to be scoped to:
User level (records owned by the user),
Business Unit level (records in the user’s BU),
Parent: Child Business Units (records in the BU and its child BUs),
or Organization-wide.
Key considerations:
BUs should be used to enforce real security boundaries - not just to mirror org charts or for reporting.
Avoid unnecessary complexity: deep BU hierarchies are hard to manage.
Moving users between BUs removes their security roles and must be done carefully.
Security Roles
Security Roles are one of the core components of Dynamics 365 CE security. They define what actions users can perform and which data they can access, based on privileges and scope.
Each user must have at least one Security Role assigned - otherwise they cannot access the system. Roles define potential access, while actual visibility depends on record ownership, Business Unit hierarchy, and record sharing.
Security Roles consist of granular privileges (Create, Read, Write, Delete, Append, Assign, Share) that can be scoped at:
User
Business Unit
Parent: Child Business Units
Organization
Out-of-the-box roles include System Administrator, System Customizer, Salesperson, and Customer Service Rep, but should typically be customized to match business needs.
Common pitfalls:
Overuse of System Administrator, poor privilege hygiene, and unmanaged role sprawl.
Teams
Teams in Dynamics 365 CE provide a flexible way to manage security and access to records, especially when users need to collaborate across Business Units or when role-based access alone is insufficient.
There are two types of Teams:
Owner Teams - can own records and have Security Roles assigned. Used for shared ownership and structured access.
Access Teams — provide dynamic access to individual records via Access Team Templates, without changing record ownership or requiring assigned roles.
Typical scenarios:
Owner Teams → permanent collaboration (Sales, Service, project teams).
Access Teams → temporary or ad-hoc access (Opportunity, Case, legal scenarios).
Key considerations:
Owner Teams are tied to a single Business Unit (though members can come from any BU).
Moving an Owner Team between BUs resets its roles and record ownership.
Access Teams are dynamic and lightweight - ideal for temporary access and external collaboration (e.g. Power Pages).
Common pitfalls:
Using Owner Teams instead of Access Teams for temporary access, uncontrolled Access Team growth, and unnecessary BU moves for Teams.
Field-Level Security
Field-Level Security in Dynamics 365 CE allows organizations to restrict access to specific fields within a record. Even if users can access the record itself, certain fields (such as sensitive personal or financial information) can be protected.
Field-Level Security controls Read, Create, and Update privileges per field, via Field Security Profiles assigned to users or teams.
Typical scenarios:
Restricting access to salary or compensation fields.
Protecting personal identification numbers (e.g. passport, tax ID).
Controlling visibility of sensitive financial details.
Key considerations:
Field security adds processing overhead - use only where necessary.
Some field types (e.g. calculated fields, rollups, certain lookups) cannot be secured.
Reports and integrations may need separate controls to enforce field-level security consistently.
Common pitfalls:
Overuse of field security, unmanaged growth of profiles, and assuming that field security automatically applies in reporting.
Record Sharing
In addition to its role-based and organizational security model, Dynamics 365 CE supports record-level sharing - enabling users to explicitly grant access to individual records to other users or teams without changing ownership.
When a record is shared, an Access Control Entry (ACE) is created, defining the granted privileges:
Read
Write
Delete
Append / Append To
Assign
Share (permission to further share the record)
Typical scenarios:
A Salesperson shares an Opportunity with a colleague from another Business Unit.
Temporary access is granted to support staff for a high-priority Case.
Cross-department collaboration on individual Accounts or Contacts.
Key considerations:
Record Sharing is additive - it grants additional access without modifying the core security role or ownership model.
Excessive use of sharing can lead to complex and difficult-to-audit access scenarios.
Use Teams where structured, reusable access is needed - use Sharing for one-off cases.
Common pitfalls:
Overusing record sharing as a substitute for proper role and team design, and neglecting to audit shared access over time.
Hierarchy Security
In addition to Business Units, Security Roles, Teams, and Record Sharing, Dynamics 365 CE also supports Hierarchy Security - a mechanism that enables managers to access their subordinates’ records, regardless of standard security role boundaries.
Hierarchy Security provides scalable, dynamic access control in scenarios where managers or executives need visibility across teams or the organizational structure.
There are two types of hierarchy security models:
Manager Hierarchy
Access is based on the Manager field in the User profile (from Azure AD or manually populated).
Example: A Sales Manager can see Opportunities owned by their direct reports and subordinaries.
Position Hierarchy
Access is based on Positions, which are defined in a configurable hierarchy.
Example: Regional Manager → Country Manager → Sales Rep.
Positions provide more flexibility than the Manager field and can model complex organizational structures.
How Hierarchy Security Works
When Hierarchy Security is enabled:
Managers gain access to the records owned by users below them in the hierarchy.
The type of access is read-only by default, but can be configured to include other privileges.
Access is enforced via the Hierarchy Depth setting - you can limit how many levels down the hierarchy the access applies to (e.g. 1 level, 2 levels, full hierarchy).
Hierarchy Security does not replace Security Roles - it is an additional layer that grants access only where users have role-based privileges to perform those actions.
Example:
A Manager has Read access to an Opportunities at the Organization level - Hierarchy Security allows them to see subordinates’ records without explicit record sharing.
Without Hierarchy Security, they would only see Opportunities they own or that are shared with them.
Typical Scenarios
Sales management visibility: Managers need to see pipeline and activity of their team members.
Customer service management: Supervisors monitor open Cases handled by agents in their team.
Executives: Need read-only access to records across the entire organization structure.
Key Considerations
Hierarchy Security helps reduce the need for manual record sharing in management scenarios.
It does not bypass role-based privileges- if a Manager lacks Delete privilege on an entity, they won’t be able to delete subordinates’ records even with hierarchy access.
Depth of access should be carefully configured to avoid granting excessive visibility.
Hierarchy Security adds overhead to security checks - test performance impact in large deployments.
Common Pitfalls
Misconfiguring hierarchy depth, resulting in manage seeing too much or too little data.
Relying solely on Manager Hierarchy when a Position Hierarchy would better model the organization.
Assuming that Hierarchy Security grants unlimited access to- it respects role-based permissions.
Related Articles
