D365 Finance & Operations Security: Roles, Duties, and Privileges Done Right

Security in Dynamics 365 Finance & Operations is hierarchical, additive, and — done wrong — the reason an auditor flags your go-live. Most projects start by cloning the "Accounting manager" role, bolting on a few permissions, and hoping. That works until segregation-of-duties conflicts surface or someone can post a journal they were never meant to touch. Here is the model, and how to build on it cleanly.

The four layers

F&O security is built from the bottom up, and each layer composes the one below it.

Layer	Grants access to	Example
Permission	A single securable object (a form, a menu item, a table, a service) at an access level	View the customer form
Privilege	A small group of permissions for one task	Maintain customer master
Duty	A set of privileges for a business activity	Maintain customer accounts
Role	A set of duties (and sometimes privileges) for a job function	Accounts receivable clerk

A user is assigned roles. Roles contain duties, duties contain privileges, privileges contain permissions. Access is the union of everything granted — like Dataverse, security is additive and you cannot subtract one grant with another.

Access levels

Each permission grants an access level on its object: No access, View, Edit, Create, Correction, Full control, Delete. The effective level is the highest granted across all assigned roles. This is why "the user has too much access" is almost always two roles overlapping, not one role being wrong.

Segregation of duties

The framework enforces conflict rules independently of roles. Under System administration > Security > Segregation of duties, you define rules like "Maintain bank accounts" must not combine with "Approve bank payments." If a role assignment would violate a rule, F&O blocks it (or logs it for review). Configure these early — retrofitting SoD after users are live means unwinding assignments people depend on.

Extending security without overlayering

You never edit Microsoft's security objects in place. You create your own in your model. The most common need — a custom form that should be reachable by an existing role — is solved by creating a privilege and extending the standard duty to reference it.

<!-- A custom privilege granting access to your menu item -->
<AxSecurityPrivilege Name="MyVendorHoldMaintain">
  <EntryPoints>
    <AxSecurityEntryPointReference>
      <Name>MyVendorHoldForm</Name>
      <ObjectType>MenuItemDisplay</ObjectType>
      <ObjectName>MyVendorHoldForm</ObjectName>
      <AccessLevel>Delete</AccessLevel>
    </AxSecurityEntryPointReference>
  </EntryPoints>
</AxSecurityPrivilege>

Then add a duty extension that pulls your privilege into the standard "Maintain vendor master" duty, so every role already granting that duty inherits your form automatically. No role editing, no overlayering, upgrade-safe.

Reading effective access

Two tools answer "why can this user do that?":

• Security diagnostics on any form (the user's record) shows which roles, duties, and privileges grant the current entry point. Start here for "who can see this form?"
• The Security configuration workspace lets you view a role's full expansion and run the Security report to export the entire role-duty-privilege tree for auditors.

For automation, the SecurableObject and role-assignment tables are queryable, and the data entities SecurityRole, SecurityUserRole, and SecurityDutyPrivilege let you export the model for review in Power BI.

Practical guidance

• Build roles for job functions, not people. "AP clerk" survives reorganizations; "Jane's role" does not.
• Prefer duty extensions over new roles when the access belongs to an existing function. Fewer roles means fewer SoD permutations to reason about.
• Set access levels deliberately. Granting Full control "to be safe" is how clerks end up able to delete master data. Default to the least level the task needs.
• Automate assignment with the Exclude and rule-based assignment options, or with Azure AD group mapping, so joiners get the right roles without a manual ticket.
• Test with a real user, not the admin. Administrators bypass most checks. Impersonate or use a test account in the actual role to see what users see.

Get the four-layer model into your head — permission, privilege, duty, role — and security stops being a pre-go-live fire drill and becomes a design you can defend line by line.