When security roles are assigned based on convenience rather than structured design, organisations inherit invisible Segregation of Duties conflicts, uncontrolled license inflation, and critical audit findings. True security governance begins with mastering the architectural hierarchy that dictates every user action inside the system.
The Four-Layer Hierarchy
Job Function
Accounts Payable Clerk, Controller, Warehouse Manager. Users are never assigned direct permissions — only roles.
Business Sub-Task
Maintain vendor bank accounts, Approve vendor payments. Duties group related privileges to simplify role construction.
Specific Access Level
Read, create, update, delete permissions on specific system objects. Privileges contain granular permissions.
AOT Software Object
Menu items, forms, reports, service operations, Web API operations. Every security evaluation resolves at this level.
What Entry Points Are and Why They Determine License Tier
Entry points are the granular software components that make up the D365 F&O application interface. They include menu items (Display, Action, Output), forms, reports, service operations, and Web API operations.
If an operational user requires a lower-tier license but is assigned a single custom role containing one entry point mapped to a higher-tier requirement, the system reclassifies their entire license consumption upward. Stripping unnecessary premium entry points is the primary mechanism for license cost optimization.
How Duties Map to Business Processes
Duties are the primary building blocks for SoD frameworks. A well-designed duty aligns with a distinct business process while isolating incompatible functions. In the Procure-to-Pay cycle:
- Duty 1: Maintain vendor master records (
VendVendorMasterMaintain) — creation and modification of vendor data and banking details - Duty 2: Approve vendor payments (
VendPaymApprove) — authorizing outgoing financial disbursements
When cleanly separated into different roles, no single user can execute both steps. When a poorly configured role combines both, the user gains end-to-end control over the disbursement lifecycle.
Standard Roles vs. Custom Roles — Risks of Each
Standard OOTB Roles: Microsoft designs them for broad operational functionality — not strict audit compliance. They frequently contain unneeded access paths, hidden SoD conflicts, and elevated license requirements that push users into premium tiers unnecessarily.
Custom Roles: Allow precise least-privilege design but carry risk through undisciplined creation. Custom roles built without verifying underlying privileges and entry points often accumulate orphaned permissions or break during One Version monthly updates.
How to View Role Contents in D365 F&O
To audit what components are packed inside a security role:
- Navigate to
System Administration → Security → Security Configuration - Select the target role to inspect its hierarchical structure — viewing associated Duties, sub-tasks, and underlying privileges
- For deeper inspection, security specialists use Visual Studio and the AOT to review exact privilege and entry-point bindings
Maintaining strict separation between role assignment and role design — ensuring that team members assigning user access cannot modify security definitions — is itself an essential governance control.
The Most Common Role Design Mistakes
A complete D365 F&O role architecture review — identifying SoD conflicts, license-inflating entry points, and role design deficiencies — delivered within 48 hours. No system access required.