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.
• F&O supports role hierarchy: you can define parent roles that automatically inherit duties and privileges from child roles, reducing duplication across similar job functions.

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

In Dataverse, column-level security uses column security profiles—separate from security roles. A column security profile grants or denies Read, Create, and Update access on specific columns, and is assigned to individual users or teams, not to security roles. Users not included in any security profile for a secured column are locked out of that column regardless of their role. In Finance & Operations, table-field access is enforced through privilege definitions within duties, which are role-specific.

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

In Dataverse, column-level security is enforced via column security profiles that are assigned per-user or per-team—two users with the same security role can see different columns depending on their individual profile assignments. In F&O, field visibility is controlled at the privilege level within duties, where table-field permissions are defined per duty, giving role-based uniformity across users who share the same role.

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

Audit log access requires specific privileges: users need the View Audit History privilege to see per-record audit history, and the View Audit Summary privilege to access the environment-wide audit summary. System Administrators have these by default; non-admin users can be granted access via a custom security role containing these privileges. 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.

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 (2026 release wave 1). 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 June 2026, reflecting the latest Dynamics 365 admin and security features including Dataverse group teams, F&O Entra ID security group integration, and Business Central security groups.

Sources

• Role-based security — Finance & Operations (Microsoft Learn, updated January 2026)
• Microsoft Entra ID security groups — Finance & Operations (Microsoft Learn, updated March 2026)
• Manage group teams — Power Platform / Dataverse (Microsoft Learn)
• Security roles and privileges for Dataverse (Microsoft Learn, updated December 2025)
• Manage Dataverse auditing (Microsoft Learn, updated April 2026)
• Control Access Using Security Groups — Business Central (Microsoft Learn, updated April 2026)

Last validated June 19, 2026.