Why one role can cover all three
Security in F&SCM is built from four layers: roles contain duties, duties contain privileges, and privileges contain permissions to menu items, tables and fields. A role like “Accounts Payable Coordinator” is meant to bundle the duties one person in that job actually needs. In practice, roles get extended over time, a temporary task here, a “just in case” duty there, until a role quietly covers far more of the process than its title suggests. [Internal link: post #6, role copying]
Maintaining vendor information, approving invoices and releasing payment are three separate duties. Nothing in Dynamics 365 stops all three from ending up in the same role, or the same user, unless somebody has explicitly told the system they must not.
What the system does check
Dynamics 365 F&SCM does have a native mechanism for this: Segregation of duties rules, found under System administration > Security > Segregation of duties. An administrator declares two duties incompatible, for example “Maintain vendor bank accounts” and “Process vendor payments”, and the system will flag any role or user assignment that combines them.
On paper, that is a control. In practice, it checks far less than it appears to. It depends entirely on someone having already identified the risky duty combination and configured a rule for it in advance; a conflict that was never declared as a rule is invisible to the system, no matter how obviously risky the combination is.
And even a configured rule only compares the two duty names it was given. It never looks at what those duties, or any other duty, actually contain. If the same vendor bank permissions also live inside a differently named duty, or were assigned to the role directly, the rule stays green while the exact conflict it was written to prevent sits in production. A control that verifies labels without verifying access is, in effect, a paper control: it proves the administration is tidy, not that the risk is covered. [Internal link: post #9, the duty-name trap; post #14, when duty names no longer match contents]
Where this shows up in an audit
This is precisely the kind of finding an external auditor looks for during a walkthrough of accounts payable controls: not whether a policy document says duties are segregated, but whether the actual role assignments in the live system reflect that policy. A vendor record, an invoice approval, and a payment release traceable to the same user is a textbook SoD exception, and finding it is genuinely difficult, because it means tracing that specific combination through every role, duty and privilege in the tenant, including access the native SoD rules never evaluate. [Internal link: post #9]
Authorization Monitoring is built for exactly this kind of check. It analyzes the Security Objects in your F&SCM environment and lets you define Critical Permissions as concrete research questions (who can maintain vendor master data, who can acknowledge receipt of goods, who can process payment to a vendor) and then automatically detects where those permissions land in the hands of the same user.
Frequently asked questions
What is segregation of duties in accounts payable?
Splitting vendor maintenance, invoice approval and payment release across different people, so no single person controls the payment cycle end to end. It is one of the most commonly tested controls in any accounts payable audit.
Does Dynamics 365 F&O prevent these conflicts automatically?
Only where a segregation of duties rule has been configured for that specific duty combination. A conflict that was never declared as a rule is not flagged, no matter how risky the combination is in practice.
Is your F&SCM environment currently able to answer “who can do all three” for every vendor-facing role you have? Request a demo to see how Authorization Monitoring surfaces that answer in minutes instead of a manual role-by-role review.
