16.1 Role-Based Security Architecture

Microsoft Dynamics 365: Finance and Operations Apps Developer Associate MB-500

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Cloud & Ecosystem Architecture

1.1 Cloud vs On-Premises Architecture & Deployment Typologies 1.2 Microsoft Ecosystem Integration & Extensibility Boundaries 1.3 Lifecycle Services (LCS) & Implementation Portal

2 Chapter 2: ALM, Environments & Unified Developer Experience

2.1 Package Deployment & Servicing 2.2 Unified Developer Experience (UDE) & Power Platform Admin Center 2.3 Environment Management & Governance

3 Chapter 3: Visual Studio Development & Metadata

3.1 Visual Studio Extension Models & Packages 3.2 Application Explorer & Element Designers 3.3 Database Synchronization & Visual Studio Debugging

4 Chapter 4: Azure DevOps Version Control & CI/CD

4.1 Version Control Architecture: TFVC vs Git in F&O 4.2 Branching, Merging & Conflict Resolution 4.3 CI/CD Build Pipelines & Artifact Generation

5 Chapter 5: UI Elements: Forms, Menus & Labels

5.1 Form Design & Form Patterns 5.2 Menus, Menu Items & Navigation 5.3 Label Files & Localization

6 Chapter 6: Data Model: Tables & Relational Design

6.1 Table Design & Extension 6.2 Views, Queries & Maps 6.3 Data Entity Design & Modeling

7 Chapter 7: Classes, Attributes & AOT Modifiers

7.1 Class Architecture & Access Modifiers 7.2 Attributes & Reflection 7.3 Event Handlers & Pre/Post Method Events

8 Chapter 8: X++ Core Programming & CRUD Operations

8.1 X++ Syntax, Control Flow & Global Functions 8.2 Data Manipulation & CRUD Logic 8.3 Best Practice Rules & Compiler Diagnostics

9 Chapter 9: Advanced OOP, Chain of Command & Extensibility

9.1 OOP Principles & QueryBuilder Class 9.2 Chain of Command (CoC) Implementation 9.3 Extensibility Patterns & Non-Breaking Changes 9.4 Event Handler Classes & Delegate Architecture 9.5 Variable Scoping, Declaration Placement & Object Lifetime

10 Chapter 10: F&O Frameworks & SysTest Unit Testing

10.1 SysOperation Framework Architecture 10.2 Workflow Framework & SysExtensionSerializer 10.3 SysTest Framework & Test Explorer

11 Chapter 11: Reporting Architecture & SSRS Reports

11.1 Reporting Architecture & Datastores 11.2 Report Data Providers & Contracts 11.3 SSRS Report Design, Deployment & Security 11.4 Determining When to Use a Specific Reporting Tool or Platform

12 Chapter 12: Business Intelligence, Workspaces & Electronic Reporting

12.1 Electronic Reporting (ER) Framework 12.2 Power BI Integration & Analytical Workspaces 12.3 Workspaces, Tiles, Lists & KPIs 12.4 Excel Integration & Office App

13 Chapter 13: Integration Patterns & Service Endpoints

13.1 Integration Pattern Evaluation & API Selection 13.2 Custom Services & SOAP/REST Endpoints 13.3 Consuming External Services & REST/SOAP APIs

14 Chapter 14: Data Management Framework (DMF) & Batch Processing

14.1 DMF Concepts, Projects & Sequencing 14.2 Entity Change Tracking & Recurring Integrations 14.3 Composite Entities & Batch OData API 14.4 Monitoring Entity Status, Availability & Job Execution

15 Chapter 15: Power Platform, Business Events & Azure Integrations

15.1 Dual-Write & Virtual Entities 15.2 Business Events Framework 15.3 Azure Key Vault Integration & Secure Storage

16 Chapter 16: Role-Based Security & Extensible Data Security

16.1 Role-Based Security Architecture 16.2 Extensible Data Security (XDS) Policies 16.3 Security Enforcement & Best Practices

17 Chapter 17: Performance Optimization & Data Access Patterns

17.1 Table & Form Caching Mechanisms 17.2 Temporary Tables & Set-Based Operations 17.3 Query Tuning, Indexes & Concurrency 17.4 Diagnostics: Trace Parser, Async & Sandbox Frameworks 17.5 Tuning Variable Scope, Buffer Lifetime & Memory Pressure

16.1 Role-Based Security Architecture

Key Takeaways Explain This Topic AI

The Dynamics 365 Finance and Operations security hierarchy is strictly ordered: Users are assigned to Security Roles, which group Duties representing business responsibilities, which contain Privileges representing specific task rights, which define Entry Points and securable Permissions.

Privilege entry points govern access to UI menus and services through five types: MenuItemDisplay, MenuItemOutput, MenuItemAction, WebResource, and ServiceOperation, evaluated against six hierarchical access levels ranging from NoAccess to Delete.

Dynamics 365 Finance and Operations evaluates multiple role assignments using a permissive union model where the highest granted access level across all assigned roles becomes the user's effective permission.

Security role assignments can be managed manually or automated through rule-based membership queries executed by the automatic role assignment batch job based on Microsoft Entra ID group membership or worker attributes.

Table field permissions and table method authorization (AOSAuthorization) provide granular defense-in-depth, overriding default access rights and preventing unauthorized direct database manipulation.

Last updated: September 2026

16.1 Role-Based Security Architecture

Quick Answer: The Role-Based Security Model (RBAC) in Dynamics 365 Finance and Operations provides a declarative, four-tier authorization hierarchy: Users are assigned Security Roles (representing business functions or personas), roles contain Duties (representing distinct business responsibilities such as approving vendor invoices), duties contain Privileges (representing rights to perform specific jobs such as maintaining customer records), and privileges grant access to Entry Points and Permissions on securable objects (tables, fields, methods). Entry points support five primary types: MenuItemDisplay , MenuItemOutput , MenuItemAction , WebResource , and ServiceOperation . Access levels scale hierarchically from NoAccess through Read , Update , Create , Correct , to Delete . Conflicting role permissions resolve via a permissive union model (the highest granted privilege wins). Role assignments can be performed manually or automated using rule-based queries evaluated by background batch jobs.

1. The Role-Based Security Hierarchy

Security in Dynamics 365 Finance and Operations is organized around business functions rather than direct object permissions. Users are never granted direct rights to tables, forms, or menu items. Instead, authorization flows strictly downward through four metadata abstraction layers: Dynamics 365 F&O Security Hierarchy

• ┌─────────────────────────────────────────────────────────────┐
• │ User │
• │ (Individual user account / identity) │
• └──────────────────────────────┬──────────────────────────────┘
• │ Assigned to
• ▼
• ┌─────────────────────────────────────────────────────────────┐
• │ Security Role │
• │ (Business persona: e.g., Accounts Payable Clerk) │
• └──────────────────────────────┬──────────────────────────────┘
• │ Composed of
• ▼
• ┌─────────────────────────────────────────────────────────────┐
• │ Duty │
• │ (Business responsibility: e.g., Maintain vendor master) │
• └──────────────────────────────┬──────────────────────────────┘
• │ Composed of
• ▼
• ┌─────────────────────────────────────────────────────────────┐
• │ Privilege │
• │ (Action-level task: e.g., View vendor invoices) │
• └──────────────────────────────┬──────────────────────────────┘
• │ Grants access to
• ▼
• ┌─────────────────────────────────────────────────────────────┐
• │ Entry Points & Securable Objects │
• │ (Menu items, forms, service operations, tables, fields) │
• └─────────────────────────────────────────────────────────────┘
• Security Element Roles and Definitions

Security Role: Represents the major business role or persona of a worker (e.g., Accountant , Purchasing Manager , Warehouse Worker ). A role consists of multiple duties and sub-roles. Roles can also contain privileges directly, although Microsoft best practices dictate that privileges should be organized into duties first to support compliance, auditability, and Segregation of Duties.

Duty: Represents a specific business process or responsibility within a department (e.g., Maintain vendor invoices , Inquire into customer payments ). Duties group related privileges together and serve as the operational boundary for Segregation of Duties (SoD) policies. A duty can belong to multiple roles, but duties cannot contain other duties.

Privilege: Represents the granular permission required to perform a discrete task or job step (e.g., Generate customer statements , Maintain sales orders ). A privilege contains one or more entry points along with specific permissions on underlying tables, fields, and server methods.

Permissions & Securable Objects: The physical assets protected by the Application Object Server (AOS), including menu items, forms, form controls, table records, individual table fields, and custom services.

Sub-Roles and Role Inheritance

Security roles support inheritance via sub-roles . An enterprise role (e.g., Regional Operations Lead ) can inherit an existing role (e.g., Inventory Clerk ) as a sub-role. All duties, privileges, and entry points belonging to the sub-role are automatically granted to users assigned to the parent role. This hierarchy simplifies administration across complex organizations with overlapping responsibilities.

2. Entry Points, Securable Objects & Access Levels

An Entry Point is a pointer within a privilege to a securable navigation element or service invocation. When a user activates a menu item or calls a web service, the AOS checks the user's effective privilege entry point permissions.

Entry Point Types

Entry Point Type Description Example Artifact

MenuItemDisplay Secures display menu items that open user interface forms, dialogs, and workspaces. CustTable , SalesTableListPage , VendInvoiceWorkspace

MenuItemOutput Secures output menu items that trigger reports, queries, and document generation (e.g., SSRS reports, Electronic Reporting configurations). CustAccountStatementExt , VendInvoiceDocument , InventValueReport

MenuItemAction Secures action menu items that execute classes, batch jobs, posting routines, or business operations. SalesFormLetter_Invoice , LedgerJournalPost , PurchOrderCancel

WebResource Secures web URLs, external resources, or legacy portal assets integrated into the client. External web components, embedded Power BI tiles, Azure integrations

ServiceOperation Secures custom SOAP or JSON/REST service operations exposed via custom service groups. CustCustomerService.create , PurchOrderService.read

Access Level Hierarchy

Entry points assign an access level ( AccessLevel ) that determines what operations the user can perform against the target form or resource. The security model uses an ordered hierarchy of access levels: Access Level Hierarchy (Union Model)

• Delete (Level 5: Full CRUD — Create, Read, Update, Delete)
• ▲
• │
• Correct (Level 4: Read, Update, Create + Edit historical time slices)
• ▲
• │
• Create (Level 3: Read, Update, Create new records)
• ▲
• │
• Update (Level 2: Read, Update existing records; cannot create or delete)
• ▲
• │
• Read (Level 1: View records in read-only mode; forms open uneditable)
• ▲
• │
• NoAccess (Level 0: Item hidden from navigation; explicit denial)

NoAccess (0): Explicitly denies access. The menu item is completely hidden from menus, navigation panes, and search bars.

Read (1): Allows viewing records. Forms open in read-only mode, and editing controls are disabled.

Update (2): Allows modifying existing records. The user cannot insert new records or delete existing rows.

Create (3): Allows creating new records and editing existing records. Inherits Read and Update .

Correct (4): Specialized access level used primarily with Date-Effective (Valid-Time-State) tables. Allows editing past and future historical records directly without creating new date-effective slices.

Delete (5): Full CRUD access. Allows reading, updating, creating, and permanently removing records.

The Permissive Union Model

When a user is assigned multiple security roles that specify conflicting access levels to the same entry point, Dynamics 365 Finance and Operations evaluates effective permissions using a permissive union model (the highest granted permission wins):

Assigned Role A Permission Assigned Role B Permission Effective User Permission Architectural Principle

NoAccess (0) Read (1) Read (1) Highest grant wins; NoAccess is level 0, not an override denial.

Read (1) Update (2) Update (2) Permissive union elevates to Update .

Read (1) Delete (5) Delete (5) Permissive union elevates to full CRUD ( Delete ).

Update (2) Create (3) Create (3) Permissive union grants record creation and modification.

Create (3) Correct (4) Correct (4) Grants temporal date-effective correction privileges.

Important

The Union Model Principle: Dynamics 365 Finance and Operations evaluates multiple role assignments additively. Unlike systems where an explicit 'Deny' trumps all 'Allows', F&O's NoAccess simply represents numeric access level 0. If Role A grants NoAccess to a menu item, but Role B grants Read , the user is granted Read . The only way to enforce row-level data restrictions that cannot be overridden by other roles is via Extensible Data Security (XDS) policies.

3. Assigning Security Roles to Users

Administrators assign security roles to user accounts through two distinct mechanisms: manual assignment and rule-based automatic assignment . Role Assignment Strategies

• ┌─────────────────────────────────────────────────────────────┐
• │ Manual Assignment │
• │ • Configured per user in System administration > Users │
• │ • Static; requires manual administrative intervention │
• │ • Best for exceptional, high-privilege administrative roles│
• └─────────────────────────────────────────────────────────────┘

• ┌─────────────────────────────────────────────────────────────┐
• │ Automatic Assignment Rules │
• │ • Query-based criteria (Entra ID groups, title, department)│
• │ • Evaluated dynamically by background batch job │
• │ • Scales across thousands of enterprise employees │
• └─────────────────────────────────────────────────────────────┘
• Manual Assignment & Legal Entity Scoping

In System administration > Users > Users , administrators assign roles directly to a user profile. Crucially, roles can be assigned globally or scoped to specific legal entities:

Grant access to all organizations: The user exercises the security role across every legal entity ( DataAreaId ) in the environment.

Grant access to specific organizations individually: The role is restricted to designated legal entities (e.g., granted Accounts Payable Clerk only in legal entity USMF and DEMO ).

Grant access by organization hierarchy: The role is granted based on an organizational hierarchy (e.g., all retail business units under the North American Operating Unit tree).

Rule-Based Automatic Role Assignment

Enterprise organizations configure dynamic membership rules under System administration > Security > Assign users to roles :

Select a security role (e.g., Employee or Warehouse Operator ).

Click Add rule to create a query-driven condition based on fields in the UserInfo , DirPerson , DirPersonUser , or HcmWorker tables.

Common criteria include:

Microsoft Entra ID (Azure AD) Security Groups: Automatically grants roles when users belong to specific corporate directory groups.

Worker Department or Job Title: Grants operational roles based on HR employment records.

Click Run automatic role assignment or schedule the recurring batch task SysSecurityUserRoleRule to evaluate rules on a schedule. When an employee transfers departments or leaves a directory group, the batch job revokes the obsolete role automatically.

4. Security Diagnostics on Forms

One of the most powerful diagnostic utilities for developers and security administrators is the Security Diagnostics tool, built directly into the Dynamics 365 Finance and Operations client framework. Security Diagnostics Inspection Workflow

• ┌─────────────────────────────────────────────────────────────┐
• │ User reports form or button issue │
• │ "I cannot see the 'Post' button on the Sales Order form" │
• └──────────────────────────────┬──────────────────────────────┘
• │
• ▼
• ┌─────────────────────────────────────────────────────────────┐
• │ Action Pane > Options > Security Diagnostics │
• │ (Opens hierarchical security analysis panel for the form) │
• └──────────────────────────────┬──────────────────────────────┘
• │
• ▼
• ┌─────────────────────────────────────────────────────────────┐
• │ Inspect Security Tree │
• │ • Identifies required Privilege: SalesOrderInvoicePost │
• │ • Identifies parent Duty: Maintain sales order invoicing │
• │ • Identifies assigned Roles containing this Duty │
• └──────────────────────────────┬──────────────────────────────┘
• │
• ▼
• ┌─────────────────────────────────────────────────────────────┐
• │ Remediation Action │
• │ Assign the identified Duty/Role to the user, or add the │
• │ Privilege to an existing custom role using extension │
• └──────────────────────────────┬──────────────────────────────┘
• Operating Security Diagnostics

Navigate to the form in question (e.g., Accounts receivable > Orders > All sales orders ).

In the Action Pane, switch to the Options tab and click Security diagnostics .

The tool displays a modal panel listing:

The exact securable menu item driving the form.

All Roles , Duties , and Privileges that grant access to that menu item.

For any specific control (such as a posting button), it identifies the specific child privilege or entry point governing that control.

Administrators can directly click Add role to user or Customize role from within the diagnostics flyout, eliminating the guesswork of searching through thousands of AOT security elements.

Caution

Diagnostic Scope Limitation: The Security Diagnostics tool analyzes metadata-based role, duty, and privilege access only . It does not evaluate Extensible Data Security (XDS) policies, record-level security, or programmatic runtime checks (e.g., X++ hasSecurityRight() or workflow status validations). If a user has the correct role but still cannot see a specific record, the root cause is typically XDS or legal entity filtering, not entry point permissions.

5. Granular Security: Table Fields & AOSAuthorization

Beyond entry points, developers can enforce fine-grained defense-in-depth directly on table fields and table methods within AOT Privileges.

Table & Field Security Permissions in Privileges

Under an AOT Privilege, developers can navigate to the Permissions > Tables node to override access rights for specific tables and fields:

Table Permissions: Set EffectiveAccess on a table (e.g., restricting CustTable to Read even if the form entry point allows Update ).

Field-Level Permissions: Override access to sensitive columns (e.g., setting CreditMax or BankAccount on CustTable to Read or NoAccess ). Even if a user has full Delete permissions on the CustTable entry point, the restricted field will render disabled or hidden across every form in the system. <!-- Metadata Representation of Field-Level Privilege Restriction -->

• <AxSecurityPrivilege xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
• <Name>CustCustomerCreditLimitMaintain</Name>
• <Label>@SYS123456</Label>
• <Permissions>
• <Table>
• <Name>CustTable</Name>
• <Fields>
• <AxSecurityPrivilegeField>
• <Name>CreditMax</Name>
• <Grant>Update</Grant>
• </AxSecurityPrivilegeField>
• </Fields>
• </Table>
• </Permissions>
• </AxSecurityPrivilege>
• Table Method Authorization: AOSAuthorization

Tables have an engine-level property called AOSAuthorization . By default, AOSAuthorization is set to None . Developers configure this property to enforce explicit authorization on table operations:

AOSAuthorization Value Behavior & Enforcement

None Default. Standard role entry point permissions govern access. No special method permissions required.

Create Explicit insert permissions on the table are verified by the AOS before any insert() completes.

Update Explicit update permissions on the table are verified by the AOS before any update() completes.

Delete Explicit delete permissions on the table are verified by the AOS before any delete() completes.

CreateUpdate Explicit permissions required for both record insertion and modification.

CreateDelete Explicit permissions required for both record insertion and deletion.

UpdateDelete Explicit permissions required for both record modification and deletion.

All Full CRUD authorization verified directly by the AOS kernel on every database mutation.

When AOSAuthorization is enabled on sensitive tables (such as ledger parameters, bank accounts, or tax setup tables), direct calls from untrusted client code or classes cannot modify the table unless the invoking user's role explicitly includes permissions for that table under a privilege's Permissions node.

• 6. Scenario Walk-Through: Configuring a Custom Accounts Payable Specialist Role
• Business Context

Contoso Enterprise requires a customized security persona for a newly created position: Junior Accounts Payable Specialist . The compliance officer outlines the following precise authorization requirements:

Vendor Viewing: Must open and view all vendor master records ( VendTable ) in read-only mode.

Invoice Entry: Must create and edit vendor invoices in the invoice workspace ( VendInvoiceWorkspace ), but must never be permitted to execute the invoice posting action ( VendInvoicePost ).

Bank Account Protection: Under no circumstances should the specialist view or modify vendor bank account numbers ( VendBankAccount table and CustVendBankAccount table), to protect against disbursement fraud.

Automated Provisioning: All employees with the job title AP Junior Specialist in Microsoft Entra ID must automatically receive this role upon provisioning.

Step-by-Step Implementation Flow Junior AP Specialist Role Construction Structure

• Privilege 1: ConVendTableInquire
• └── Entry Point: VendTable (MenuItemDisplay) -> AccessLevel: Read

• Privilege 2: ConVendInvoiceMaintainNoPost
• ├── Entry Point: VendInvoiceWorkspace (MenuItemDisplay) -> AccessLevel: Create
• └── Permissions > Tables > VendBankAccount -> EffectiveAccess: NoAccess

• Duty: ConMaintainVendorInvoicesJunior
• ├── Includes: ConVendTableInquire
• └── Includes: ConVendInvoiceMaintainNoPost

• Security Role: ConJuniorAPSpecialistRole
• ├── Includes Duty: ConMaintainVendorInvoicesJunior
• └── Automated Assignment Rule: Query on HcmWorker.Title == 'AP Junior Specialist'

Create Privileges in Visual Studio:

Create ConVendTableInquire . Add entry point VendTable (MenuItemDisplay) with AccessLevel = Read .

Create ConVendInvoiceMaintainNoPost . Add entry point VendInvoiceWorkspace (MenuItemDisplay) with AccessLevel = Create . Crucially, omit the action menu item SalesFormLetter_Invoice or VendInvoicePost .

Under ConVendInvoiceMaintainNoPost > Permissions > Tables , add VendBankAccount and set EffectiveAccess = NoAccess .

Group Privileges into a Custom Duty:

Create Duty ConMaintainVendorInvoicesJunior .

Add both privileges to the duty.

Create the Security Role:

Create Role ConJuniorAPSpecialistRole .

Assign ConMaintainVendorInvoicesJunior to the role.

Configure Automated Assignment Rule:

In the F&O client, navigate to System administration > Security > Assign users to roles .

Select ConJuniorAPSpecialistRole and click Add rule .

Configure query: Join UserInfo to DirPersonUser to DirPerson to HcmWorker . Add range: HcmWorker.Title == "AP Junior Specialist" .

Run the automatic role assignment job to verify user mapping.

Verify Security:

Log in as a test junior AP clerk.

Open the vendor list; confirm the form is read-only.

Open invoice entry; confirm new invoices can be keyed, but the Post button is missing or disabled.

Open vendor banking details; confirm the tab and fields are completely hidden.

7. Exam Traps & Architectural Pitfalls

Area Common Exam Trap Correct Architectural Fact

User Assignment Assuming users can be assigned directly to Duties or Privileges. Users can only be assigned to Security Roles . Duties and privileges cannot be assigned directly to user accounts.

Role Hierarchy Believing Duties contain other Duties or Roles. The hierarchy is strictly one-way: Roles contain Duties and Privileges; Duties contain Privileges; Privileges contain Entry Points and Permissions. Duties cannot contain sub-duties.

Access Evaluation Assuming the most restrictive permission wins when a user has multiple roles. Dynamics 365 F&O uses a permissive union model . The highest granted access level across all assigned roles becomes the effective access right.

Explicit Denial Assuming NoAccess acts as an absolute deny that overrides Read in another role. NoAccess represents numeric level 0. If Role A grants NoAccess and Role B grants Read , effective access is Read .

Diagnostics Relying on Security Diagnostics to troubleshoot missing records on a grid. Security Diagnostics only diagnoses menu item, duty, and privilege metadata. Missing rows on a grid are caused by XDS, legal entity filters, or form query ranges.

Field Security Securing form control properties instead of table field metadata. Securing form controls only protects that single form UI. Securing the field under a Privilege protects the field across all forms, data entities, OData calls, and reports.

Loading diagram... Role-Based Security Model Hierarchy and Access Evaluation