Security

The Security Framework in D365 F&O implements a role-based access control (RBAC) model with a strict hierarchy: Roles → Duties → Privileges → Entry Points. This hierarchy ensures that user access is defined at a granular level and composed upward into meaningful business role assignments.

---

The Security Hierarchy

Level	Object	Description
Role	AxSecurityRole	The top-level assignment unit. Users are assigned to roles. A role aggregates duties, privileges, and sub-roles.
Duty	AxSecurityDuty	A business responsibility that maps to a group of related privileges (e.g., "Maintain vendor invoices").
Privilege	AxSecurityPrivilege	A specific permission that grants access to one or more entry points with a defined access level.
Entry Point	AxSecurityEntryPointReference	A menu item (Display, Action, Output) or service operation. The entry point is the actual gate to application functionality.
Policy	AxSecurityPolicy	A row-level security filter (Extensible Data Security / XDS) that restricts which records a user can see based on their role context.

---

Code vs Database — Two Approaches

Security objects can be maintained in two locations, each with trade-offs:

In the Codebase (AOT)

Developers create and maintain security roles, duties, and privileges as AOT objects in Visual Studio. This is the recommended approach for custom solutions.

Advantages:

• Version-controlled and deployable through the standard ALM pipeline.
• Reviewed in code reviews alongside functional changes.
• Consistent across environments (dev → test → production).
• Can leverage extensions to modify standard Microsoft security objects.

Disadvantages:

• Requires developer involvement for any security changes.
• Changes require a build and deployment cycle.

In the Database (UI Configuration)

Security administrators configure roles, duties, and privileges directly in the D365 client at System administration → Security.

Advantages:

• No developer involvement — security administrators can act independently.
• Changes take effect immediately without deployment.
• Rapid iteration during initial setup or audits.

Disadvantages:

• Not version-controlled by default.
• Difficult to promote consistently across environments.
• Risk of configuration drift between environments.
• Database-level changes override codebase definitions — if a role is modified in the database, the AOT version is overridden at runtime.

Override Behaviour

The database configuration takes precedence over AOT definitions. When a security object exists in both the AOT and the database, the database version is used at runtime. This means:

• A security administrator can add duties to a role in the database that were not defined in the AOT.
• A security administrator can remove privileges that were defined in the AOT.
• After a deployment that updates AOT security objects, the database overrides are preserved — the deployment does not reset manual database changes.

warning

If you maintain security in the database, establish a process for documenting and auditing changes. Consider using the Security configuration export/import functionality to back up database security settings and promote them across environments.

---

Best Practices

1. Define security in the AOT for all custom features — this ensures version control, deployability, and review.
2. Use the duty layer — don't assign privileges directly to roles. Group privileges into meaningful duties that map to business responsibilities. This makes role management manageable as the number of privileges grows.
3. Follow the principle of least privilege — grant only the minimum access level needed.
4. Name consistently — use patterns like MyModuleMaintain (duty), MyFormView (privilege) for discoverability.
5. Use extensions rather than overlaying standard Microsoft security objects.
6. Test security using the "Set user security" feature and security role testing tools.

---

Sub-pages

• Roles — security role objects with duties, privileges, and sub-roles.
• Duties — duty objects that group privileges.
• Privileges — privilege objects with entry point and permission grants.
• Policies — XDS row-level security policies.