Dynamics 365 Role-Based Security: Complete Guide to Access Control

Overview: Dynamics 365 Security Architecture

Dynamics 365 uses a layered, hierarchical security model that operates across multiple dimensions:

• Business Units: Organizational divisions that segment data and control record access (F&O, Dataverse).
• Security Roles: Named collections of duties that define what users can do.
• Duties: Groups of privileges organized by business area (e.g., Sales Duty, Accounts Payable Duty).
• Privileges: Atomic permissions that grant Create, Read, Update, Delete, Assign, Share, or Append actions on specific tables.
• Field-Level Security (FLS): Restrictions on column visibility and editability by role.
• Record-Level Security: Row-based filtering enforced through owner, sharing rules, and team membership.
• Teams & Sharing Rules: Mechanisms for delegating access without explicit role assignment.
• Audit Logs: Trails of all data modifications for compliance and forensics.

This multi-dimensional approach allows fine-grained control but requires careful planning and configuration to avoid both security gaps and over-restrictions that impede workflow.

Security Roles, Duties, and Privileges

The foundation of D365 access control is the security role—a named container of duties that can be assigned to users, teams, or both.

How Roles, Duties, and Privileges Relate

A security role contains zero or more duties. Each duty contains zero or more privileges. A privilege grants a specific action (CRUD, Assign, Share, Append) on a specific table to a user holding that role.

Component	Definition	Example	Scope
Security Role	Named container of duties assigned to users	Sales Manager, Accountant, System Administrator	User or team
Duty	Collection of privileges grouped by business function	Sales Duty, General Ledger Duty, Accounts Payable Duty	Role
Privilege	Atomic permission granting CRUD/Assign/Share/Append on a table	Create Lead, Read Account, Update Opportunity, Delete Invoice	Duty

Out-of-Box vs. Custom Roles

Microsoft ships predefined security roles (System Administrator, System Customizer, Sales Manager, Customer Service Representative, etc.) designed for common job functions. However, these roles often grant excessive permissions and must be audited and customized to match your organization’s actual job duties and segregation-of-duties (SOD) requirements.

Key considerations:

• System Administrator role has unrestricted access to all data and configuration; assign sparingly.
• Custom roles should follow the principle of least privilege—grant only the duties and privileges required for the job.
• Duty-based role composition (in F&O) allows reuse and consistency across role definitions.
• Role inheritance is not supported; changes to parent duties require re-evaluation of all dependent roles.

Business Unit Hierarchy and Organizational Structure

In Dataverse and F&O, business units represent your organization’s structure and control record ownership and access.

Business Unit Architecture in Dataverse

Every Dataverse organization contains a root business unit and zero or more child business units. Each record (Account, Contact, Opportunity, etc.) is owned by a business unit. When you assign a security role to a user, that role’s access scope is defined relative to the user’s business unit:

• Business Unit level: User can access records owned by their business unit only.
• Parent: Child level: User can access records owned by their business unit and all child business units.
• Organization level: User can access all records across all business units (equivalent to System Administrator for that privilege).

Organization Units (OrgUnits) in Finance & Operations

F&O uses organization units (OrgUnits)—legal entities, operating units, and departments—to control record access. Security roles are linked to OrgUnits, and users can only access records within their assigned OrgUnit and any child OrgUnits.

Best Practices for Business Unit / OrgUnit Design

• Align business unit hierarchy with your organization’s actual structure (divisions, regions, departments).
• Avoid overly deep hierarchies; aim for 3–5 levels maximum for performance and manageability.
• Use a single root business unit; do not create multiple independent hierarchies.
• Regularly audit business unit membership to prevent orphaned records and access gaps.

Record-Level Security and Sharing Rules

Record-level security (RLS) controls who can access individual records, separate from role-based access. A user may have read privilege on the Account table but only see accounts they own or have been granted access to via sharing.

Ownership & Record Owner Scope

In Dataverse, every record has an owner (a user or team). When a user creates a record, they become the owner. The owner always has full access to that record, regardless of the role’s privilege level.

The owner scope in a privilege determines what owners a user can see:

• User: User can only access records they own.
• Business Unit: User can access records owned by users in their business unit.
• Parent: Child: User can access records owned by users in their business unit and child business units.
• Organization: User can access records owned by anyone in the organization.

Sharing Rules & Record Sharing

Sharing rules automatically grant access to records based on attributes or relationships. For example, a rule might grant all sales representatives in the “North America” region read and update access to all accounts tagged with that region.

Manual sharing allows the record owner to grant specific users or teams access to a record outside of role membership.

Access Teams for Dynamic Delegation

An access team is a user-created team with no predefined membership. Managers can add and remove users as needed, and members inherit the team’s shared access to records. This avoids the overhead of creating permanent teams for every small collaboration.

Field-Level Security (FLS) and Column Restrictions

While record-level security controls row access, field-level security controls column (attribute) visibility and editability.

How FLS Works

You can assign FLS profiles to security roles, restricting visibility and create/update/read permissions on specific columns. If a user’s role has FLS on a column, that user cannot see or edit that column, even if they have read/update privilege on the entire table.

Common use cases:

• Hide salary or cost data from non-HR roles.
• Restrict SSN, payment method, or health information visibility.
• Limit commission or discount visibility to sales managers only.
• Prevent junior staff from editing sensitive pricing or cost fields.

FLS Scope and Depth in D365

FLS is applied by role; users with the same role see identical columns. Unlike Dataverse, F&O FLS is enforced at the privilege level and is not role-specific but rather table-specific, allowing more granular control but requiring careful privilege definition.

Team-Based Security and Ownership Models

Teams allow you to group users and grant them collective access to records or shared mailboxes without assigning individual roles to every team member.

Owner Teams vs. Access Teams

Owner teams can own records and have a predefined role that all members inherit. Use owner teams for stable groups with consistent roles (e.g., the Sales Department team).

Access teams have no predefined role and are created to share specific records or provide temporary collaboration. Use access teams for ad hoc needs (e.g., a task force assembled for one project).

Team Records & Membership Management

When a team owns a record, all team members have equal access based on the record’s ownership scope. Adding or removing a user from the team immediately grants or revokes access to all team-owned records. This simplifies bulk access changes but requires careful team membership governance.

Dataverse-Specific Security Controls

Dataverse (used by Sales, Customer Service, Marketing, and custom model-driven apps) enforces security through a combination of roles, business units, teams, and sharing rules.

Dataverse Security Enforcement Flow

When a Dataverse user requests access to a record:

1. The system checks if the user has privilege on that record’s table.
2. If yes, it evaluates record-level access: owner scope, sharing rules, team membership.
3. If the user has access, FLS rules are applied to filter visible columns.
4. The record and permitted columns are returned to the user.

Business Unit & Parent-Child Hierarchy

In Dataverse, security is first filtered by business unit. A user in business unit “Sales East” with Business Unit-scoped read privilege sees only records owned by users in Sales East and its child business units, not records owned by Sales West.

Finance & Operations Security Roles and Duties

F&O (Dynamics 365 Finance, Supply Chain Management, HR) uses a duty-based security model similar to Dataverse but enforced through organization units and legal entities.

Duties & Privilege Composition

F&O ships with 300+ predefined duties (e.g., General Ledger Clerk, Accounts Payable Manager, Procurement Agent). Each duty is a collection of privileges that allow specific menu access and table operations.

A user assigned to the Accountant role receives all duties in that role. If two duties overlap (both contain a Create Account privilege), the user receives that privilege once.

Table Permissions & Access

F&O table permissions are more granular than Dataverse. Each table has a permission (e.g., “Read CustTable”, “Update VendTable”), and privileges explicitly grant or deny that permission. If a user’s duty does not include a permission, the user cannot access that table.

Audit Logging and Compliance Requirements

To satisfy regulatory requirements (SOX, GDPR, HIPAA, PCI-DSS), you must enable and properly configure audit logging on sensitive tables and fields.

Audit Log Scope & Contents

Dynamics 365 audit logs record:

• User identity and timestamp of the change.
• Table & Record ID that was modified.
• Old & new values for each column (if enabled).
• Action type: Create, Update, Delete, Share, Assign.

Configuring Audit for Sensitive Data

Best practice: Enable auditing on all tables handling PII, financial data, or health information. Configure audit retention per your regulatory requirements (typically 3–7 years). Regularly export and archive audit logs to meet legal hold and e-discovery obligations.

Audit Log Access & Governance

Only System Administrators can access audit logs in D365. To prevent log tampering, ensure audit data is exported regularly to a separate, read-only storage system (Azure Data Lake, Synapse, etc.). Monitor for suspicious access patterns (bulk deletes, role changes, privilege escalations) using analytics or SIEM tools.

Security Configuration Best Practices

1. Principle of Least Privilege: Assign users the minimum duties and privileges required for their job. Avoid assigning System Administrator or System Customizer roles to end users.

2. Regular Role & Duty Audits: Quarterly, review all active roles and user role assignments. Identify and remove unused roles, and verify role compositions align with current job functions.

3. Segregation of Duties (SOD): Ensure incompatible duties are never assigned to the same user. For example, a user who can approve purchase orders should not also be able to create vendors. Use SOD tools in F&O to detect violations.

4. Business Unit & Team Governance: Maintain a clear, documented business unit and team structure. Assign users to business units and teams based on organizational hierarchy, not ad hoc preferences.

5. Audit & Monitor Access: Enable auditing on sensitive tables, review audit logs monthly, and alert on high-risk actions (role assignment, privilege escalation, bulk deletes).

6. Test Security Configuration in UAT: Before going live, thoroughly test user access in a UAT environment. Verify that each role grants intended access and denies unintended access.

7. Document Security Decisions: Maintain a security control matrix documenting why each role, duty, and privilege assignment exists. This aids compliance audits and onboarding of new administrators.

Common Misconfigurations and How to Fix Them

1. Excessive System Administrator Assignments

Problem: Many end users are assigned the System Administrator role for convenience, allowing them to modify data, configuration, and security settings without oversight.

Fix: Audit all users with System Administrator role. Downgrade non-IT users to a custom role with only required duties. Restrict System Administrator assignment to IT and senior functional leads.

2. Disabled Field-Level Security

Problem: FLS is not enabled on sensitive columns (salary, payment method, SSN), allowing unauthorized users to view this data.

Fix: Identify sensitive columns, create FLS profiles restricting visibility by role, and apply profiles to all non-admin roles. Test FLS in UAT to confirm visibility restrictions.

3. Overly Broad Record-Level Access

Problem: All sales representatives are assigned Organization-level read privilege on all accounts, allowing them to see competitors’ confidential account data.

Fix: Change privilege scope to User or Business Unit. Create sharing rules to grant access only to accounts in the user’s region or territory. Regularly audit sharing rule scope.

4. Inadequate Audit Retention

Problem: Audit logs are retained for only 30 days, making it impossible to investigate historical data changes for compliance audits.

Fix: Increase audit retention to match regulatory requirements (typically 7 years). Export audit logs to a read-only archive monthly. Set up alerts for audit log modifications or deletions.

5. Missing Segregation of Duties

Problem: The same user can create purchase orders, approve purchase orders, and post invoices—violating SOD.

Fix: Use F&O’s SOD framework to identify conflicts. Create separate roles for order creation, approval, and posting. Assign users to roles aligned with their actual job duties.

Frequently Asked Questions

Q: Can I delegate security role assignment to department managers without granting System Administrator role?

A: Yes, but with caution. You can grant a custom role that includes the “Maintain User Roles” privilege, allowing managers to assign predefined roles to their team members. However, monitor this delegation to prevent privilege escalation. Ideally, centralize role assignment in IT.

Q: How do I prevent users from seeing each other’s records in Dataverse?

A: Use User-level ownership scope on sensitive privileges (e.g., read/update Opportunity). This restricts visibility to records the user owns. If some users need to see others’ records, use manual sharing or sharing rules rather than broad role membership.

Q: What happens to records owned by a user who is deleted or deactivated?

A: Owned records remain in the system but are no longer accessible by the deactivated user. A System Administrator must reassign ownership to another user or team to maintain access. Plan for a record reassignment process when offboarding employees.

Q: Can I assign a security role to a team in Finance & Operations?

A: No, F&O roles are assigned to users only, not teams. However, you can create owner teams and have the team own records; team members inherit the team’s implied access. For access teams, ensure team members have roles that grant the necessary privileges.

Q: How do I audit who has access to a specific record in Dataverse?

A: Open the record, click “Share”, and view the access list. This shows direct owners, team owners, and users granted access via sharing. However, this does not show users who can access the record via a sharing rule; you must check sharing rule definitions separately.

Q: Is field-level security enforced at the API level or only in the UI?

A: FLS is enforced at the data access layer, affecting both UI and API calls. Users cannot retrieve FLS-restricted columns through REST, SOAP, SDK, or OData APIs. This prevents data leakage through alternative access methods.

Q: Can I use Microsoft Entra ID (Azure AD) group membership to automatically assign D365 security roles?

A: Not directly. D365 does not dynamically sync Azure AD group membership to roles. However, you can use Power Automate or a custom sync solution to grant roles based on AD group membership, updating role assignments when AD group membership changes.

Q: What is the performance impact of enabling audit logging on all tables?

A: Audit logging introduces a small write overhead (typically <5% for most systems). Microsoft recommends auditing high-risk tables (financial, PII) but may disable auditing on high-volume transactional tables (e.g., ledger entries, sales lines) if performance becomes an issue. Use Azure Synapse to analyze audit logs without impacting production.

Methodology

Dataset: This article synthesizes Microsoft Dynamics 365 official documentation (Admin & Security Center, Dataverse Security Model, F&O Role-Based Access Control), best practices from certified Dynamics 365 Enterprise Resource Planning and Dynamics 365 Fundamentals exams, and real-world security audit findings from Dynamics implementations.

Analytical Approach: We reviewed the security architecture across three major D365 product lines (Dataverse-based Sales/Service/Marketing, Finance & Operations, and Business Central), mapped common security components (roles, duties, privileges, business units), identified key differences in enforcement, and compiled a consolidated reference guide. Comparisons highlight architectural differences between products to help you apply the right security model to your scenario.

Limitations: This guide covers on-premises and cloud deployments of Dynamics 365 (2024 release). Custom security extensions, third-party identity providers, and advanced analytical security scenarios are outside scope. For compliance-specific requirements (HIPAA, GDPR, FedRAMP), consult Microsoft’s compliance documentation and your implementation partner.

Data Currency: Last updated March 2026, reflecting the latest Dynamics 365 admin and security features.