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. There is no deny layer. If the clerk role grants View and a second role grants Delete, the user has Delete. Fixing "too much access" means removing a role or a duty, not adding a third role that "takes away" posting.

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. Grant the lowest level the task needs. A custom form that only holds a hold flag does not need Delete because a maintain privilege happened to ship with it.

Do not clone Accounting manager

Accounting manager is a job function Microsoft composed for a broad finance lead. It bundles duties you have not read. Cloning it copies that bundle into a role with a new name. You now own a snapshot.

The clone often contains both a maintain duty and an approve duty an auditor wants split. Microsoft can add a duty to Accounting manager later; your clone does not receive it. The name drifts from "Accounting manager - Contoso" to Jane. Jane leaves. Her extra duties stay.

Build a role named for the job you actually staff: AP clerk, AP invoice approver, bank reconciliation. Add only the duties that job needs. If the job needs one extra form that already sits in a standard duty, extend the duty. If the job is a subset of Accounting manager, start empty and add duties. Subtraction from a clone is how leftover posting privileges survive.

Clone only when you are staffing Microsoft's job function and need a copy to attach extra duties. Even then, run SoD against the clone before the first user assignment.

Segregation of duties, walked

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."

Walk it once before anyone is live:

1. Write the rule: duty A = Maintain bank accounts, duty B = Approve bank payments.
2. Verify existing roles. F&O lists roles that already contain both. A cloned Accounting manager often shows up. Do not delete the rule to "resolve" it. Split the role: one with A, one with B.
3. Assign a test user only the maintain role; confirm they cannot approve. Reverse on a second user.
4. Assign both roles to one test user. The assignment should block, or land in unresolved conflicts, depending on enforcement. If it assigns silently, the rule is not active.

SoD watches duty combinations on the user, not a form at runtime. A custom duty that hides both actions in one name will not hit this rule. Keep privileges in the duties the rule names. Overrides exist for a tiny finance team. They are an audit record. If every AP clerk needs one, the roles are wrong. Configure SoD early; retrofitting 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. If the form should not delete vendor holds, do not copy Delete from the sample — use Edit.

Duty extension is the wrong move when the form is a new job. A vendor-hold approver who should not maintain vendors needs a new duty and a new role. Extending Maintain vendor master would give every vendor-master clerk the approval form.

Reading effective access when someone can "do too much"

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

• Security diagnostics on a form shows which roles, duties, and privileges grant the current entry point. Start here.
• The Security configuration workspace expands a role and the Security report exports the role-duty-privilege tree for auditors.

Walk "Sam can post a payment journal" like this: open diagnostics on that journal form for Sam, note the privilege, expand Sam's roles until you see it. You will usually find a second role — a project role, a cloned manager, a temp assignment. Remove it on a test copy of Sam first. If diagnostics show no privilege and Sam can still post, you are on an administrator bypass or a different entry point (batch, another menu item). Administrators bypass most checks. Impersonate a real role.

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.

When not to, and a checklist

• Not a new role if the access belongs to an existing function. Prefer a duty extension. Fewer roles means fewer SoD permutations.
• Not a duty extension if the people who have that duty must not get the new form.
• Not a privilege on a role as a shortcut around duties. Privileges on roles skip the activity layer SoD is built on.
• Not the admin user for UAT. You will sign off a form the clerk cannot open.

Build roles for job functions, not people. Set access levels deliberately — Full control "to be safe" is how clerks delete master data. Automate assignment with Exclude, rule-based assignment, or Azure AD group mapping. Test with a real user. Run SoD verify after every role change, not only before the audit.

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.