@Huma Selot CU200816...
Here is the architectural approach that works:
Building custom SoD rules at the right level:
Always define SoD rules at the Duty level — not the Role level and not the Privilege level. Duty level is the correct abstraction because it represents a business process activity rather than a technical permission. This makes your rules readable to auditors and stable across role changes.
Navigate to System administration > Security > Segregation of duties > Segregation of duties rules > New. Define each rule as a conflict between two specific duties — for example PurchOrderMaintain conflicts with PurchOrderApprove. The system will flag any user assigned both duties simultaneously.
Preventing silent rule breakage from updates:
The biggest risk is a developer adding a new privilege to an existing duty — or creating a new duty — that effectively replicates a conflicting capability without triggering your existing SoD rule. Three things to prevent this:
Document every SoD rule with a business rationale — not just the duty names. When developers see why a rule exists they are less likely to inadvertently break it through new privilege additions.
Run the SoD conflicts report after every platform update and security change — System administration > Security > Segregation of duties > Segregation of duties conflicts. Review the delta — new conflicts appearing or existing conflicts disappearing both indicate something changed.
Add SoD conflict report review to your change management process — any security role or duty change must include a SoD report run before and after as part of the approval documentation.
Frameworks for mapping custom duty conflicts before configuring:
Build a conflict matrix in Excel before touching the system. Columns are duties, rows are duties, cells mark whether the intersection is a conflict and why. Map your business processes — AP, AR, GL, Procurement, Inventory — and identify every combination where one person controlling both activities creates fraud risk or audit failure.
This matrix becomes your living SoD rulebook. Every new rule added to D365 F&O traces back to a cell in this matrix with a documented business justification. Auditors love this — it shows your SoD framework is intentional not accidental.
If it helps, mark answered.
