D365 F&O Security Governance Phase 3 — Role Engineering
A manual compensating control is a band-aid. Role Engineering is the permanent fix. Discover the exact steps to split Frank's toxic AP Manager role and prove the SoD conflict is mathematically eliminated.
The formal governance policy governing all D365 custom role creation, naming conventions, and exception approvals. Ready for external audit submission.
In Phase 2 of our governance engagement for Sajeed Mullaji Consulting, we proved the danger. We ran the Segregation of Duties detection engine and exposed Frank in the penalty box.
His profile held a toxic overlap: the Accounts Payable Manager role combined with the Accounts Payable Payments Clerk role. He possessed the systemic capability to create a fictitious vendor, alter bank routing details, and approve a fraudulent payment to himself with zero secondary human oversight.
We managed that initial exposure using a manual compensating control. But a manual compensating control is a band-aid. It relies on human vigilance, and human vigilance degrades over time.
Today, in Phase 3, we execute D365 F&O role engineering. We are going to surgically remove the threat from the architecture permanently.
Here is the exact, step-by-step technical execution framework for engineering least-privilege custom roles without breaking your business.
Step 1: Why Standard Microsoft Roles are Dangerous
Microsoft ships Dynamics 365 Finance and Operations with bloated, out-of-the-box security roles designed for rapid demonstrations, not enterprise security.
Standard roles are built to satisfy every possible operational edge-case. Because of this, they contain far more access than any single user requires.
Assigning standard roles to production users creates immediate Segregation of Duties conflicts and over-provisioned license costs. Relying on default Microsoft security is the primary reason organizations fail their IT General Controls audits.
Step 2: The Golden Rule — Never Modify Standard Roles
When undertaking D365 custom role design, the golden rule is absolute: Never touch a standard Microsoft role.
If you modify a native Microsoft security object directly, you forfeit your baseline integrity. When Microsoft pushes updates, your modified standard objects risk corruption or unexpected permission expansion.
Instead, always duplicate. Your custom roles remain controlled, independent, and immune to automated Microsoft role bloat.
Adhere strictly to a professional naming convention. Prefix all custom artifacts with your corporate identifier—in our practice, we use SMC - [Role Name] - [Description].
Step 3: Duplicate the Accounts Payable Manager Role
Let us execute the duplication in the security configuration framework.
Navigate to System administration → Security → Security configuration.
Click on the Roles tab in the left-hand column. Search for and select Accounts payable manager.
Click Duplicate in the top action pane.
When the system prompts you for a name, enter: SMC - Accounts Payable Manager - No Vendor Master. Click OK.
You now possess an exact, isolated copy of the standard role living safely within your unpublished objects container.
Step 4: Remove the Toxic Duty
Now we excise the root cause of the $250,000 audit finding.
Ensure your new role SMC - Accounts Payable Manager - No Vendor Master is selected in the Roles column.
Click on the Duties tab in the middle column.
Use the filter function to find Maintain vendor master (the duty that grants vendor creation and bank detail modification rights).
Select it, and click Remove in the action pane.
This single action eliminates the D365 SoD role split violation. Frank can no longer create or modify vendors.
Step 5: Add the Read-Only Equivalent for Business Continuity
Junior consultants often fail at this exact junction. If you strip Maintain vendor master and stop there, the system crashes operationally.
Frank is an AP clerk. When he opens a vendor dropdown menu to process a legitimate payment, the system checks his underlying access. If he has zero visibility into the vendor master, the system throws an Access Denied error. You cured the fraud risk, but you killed the business.
To maintain business continuity, we must inject a read-only equivalent.
While still on the Duties tab, click Add references.
Search for Inquire into vendor master. Select it and click OK.
This is the critical distinction: Frank retains full visibility to view vendor data required for payment processing, but his systemic permission to alter master data is permanently revoked.
Step 6: Publish the Custom Role
With the surgical alterations complete, we compile and push the new role live.
Navigate to the Unpublished objects tab at the top right of the Security Configuration workspace.
Select your newly engineered role: SMC - Accounts Payable Manager - No Vendor Master.
Click Publish selection.
The system validates the node mapping, compiles the security matrix, and writes the clean custom role to the production database.
Step 7: Swap Frank's Roles
The custom role is live, but Frank is still assigned the bloated standard role. We must execute the swap.
Navigate to System administration → Users → Users.
Select Frank from the user grid.
Click Assign roles in the action pane.
Select and check your custom role: SMC - Accounts Payable Manager - No Vendor Master. Click OK.
Next, select Frank's old assignment—the standard Accounts payable manager role—and click Remove.
Frank's profile is now governed exclusively by your least-privilege design.
Step 8: Verify Business Continuity
Before declaring victory, test the user experience.
Log into a test session as Frank.
Navigate to Accounts payable → Vendors → All vendors.
Confirm that the vendor directory loads correctly and Frank can view existing vendor records.
However, verify that the New, Edit, and Delete buttons across the action pane are entirely greyed out.
Frank can view vendors to cross-reference invoices, but he cannot create, modify, or delete master data. Business continuity is preserved; risk is neutralized.
Step 9: Prove the SoD Conflict is Resolved
Now we test the environment against the audit engine.
Navigate to System administration → Security → Segregation of duties → Verify compliance of user-role assignments. Click OK to run the batch job.
Once complete, navigate to Segregation of duties conflicts.
Review the grid. Frank's name is entirely absent.
The toxic overlap no longer exists. The system registers zero compliance violations for this user-role combination.
Step 10: Export Clean Audit Evidence
Auditors do not accept verbal assurances. They require cryptographic proof.
From the clean conflicts grid, click the Open in Microsoft Office icon and export the records to Excel.
Save this document as your immutable audit evidence. When the external audit team arrives, this export proves that the material weakness identified in Phase 2 has been permanently resolved through proper D365 security role duplication and least-privilege engineering.
Proactive Executive Q&A
1. Will custom roles break when Microsoft releases updates?
No. Standard Microsoft roles are static objects upon release. When Microsoft updates a standard role in a monthly platform release, your custom SMC role remains completely independent. Your custom role acts as a controlled governance version. You only incorporate new Microsoft features if your business process explicitly demands them, protecting your environment from forced security instability.
2. Do we repeat this manual process for all 10 AP Clerks?
No. Role engineering is an architectural exercise, not an administrative chore. You engineer the custom role once. Then, you apply that clean custom role at the user assignment layer across all active accounts payable personnel in bulk. The fix is systemic and scales instantly across the department.
3. Does removing a duty change our Microsoft license cost?
No. In this specific scenario, while the risk was eliminated, Frank retains his other high-privilege AP tasks, meaning his license tier remains unchanged. However, addressing this proactively satisfies the CFO's immediate financial concern regarding software expenditure during security remediation.
4. What about 100 conflicts across 20 modules — is this scalable?
Manual Excel tracking works for single-module remediation, but enterprise scale requires automation. When managing security across massive multi-entity environments, organizations utilize automated governance frameworks to digitize the engineering workflow, enforce policy approvals, and deploy custom roles without administrative overhead.
License Impact Note
CFOs evaluating security remediation invariably ask whether removing high-privilege duties lowers software subscription costs. In Frank's case, while the Segregation of Duties risk was entirely eliminated, his remaining responsibilities as Accounts Payable Manager still require full functional access. Consequently, his Microsoft license tier remains unchanged at D365 Finance.
What Comes Next
With our structural access risks neutralized in Phase 3, we transition directly into Phase 4: License Optimization. The clean, least-privilege role architecture we just engineered serves as the foundational baseline for auditing user activity and safely downgrading over-provisioned accounts to lower-cost tiers. This systematic review recovers significant annual Microsoft subscription spend without sacrificing operational capability.
Downloads and Resources
The complete Role Engineering Matrix Excel template and the formal Corporate Security Role Standard Policy Word document are available for immediate download at sajeedmullaji.com.
Visit sajeedmullaji.com to download the complete Role Engineering Matrix and Corporate Security Role Standard Policy — and to explore the full D365 F&O Governance Roadmap series.
Executive Q&A: Advanced D365 F&O Role Engineering
Q1: If we deploy custom roles using the SMC prefix across our production environment, will this custom naming convention complicate our eventual migration to future D365 platform updates or LCS/Succession tooling?
Answer: Not at all. Microsoft’s security configuration framework treats custom roles created via the UI identically to native objects during upgrades, and custom prefixes ensure your internal administrative modifications remain easily distinguishable from standard Microsoft packages. This practice prevents upgrade scripts from inadvertently overwriting your audit-defensible security adjustments.
Q2: Our internal IT team argues that duplicating roles creates excessive clutter in the Security Configuration workspace. How do we maintain long-term administrative hygiene?
Answer: Administrative clutter is easily controlled by enforcing strict organizational ownership and retiring obsolete unpublished drafts during quarterly housekeeping reviews. Maintaining a clean repository of documented custom roles is an operational necessity for passing IT General Controls audits, far outweighing the minor visual overhead in the configuration grid.
Q3: When an external Big Four auditor inspects our custom roles, what specific documentation do they request beyond the Excel export of our clean SoD conflicts grid?
Answer: Auditors will request the signed Role Engineering Matrix, the corresponding Corporate Security Role Standard Policy, and the exact Before-and-After definition comparisons proving that toxic duties were excised while read-only navigational equivalents were preserved. Providing this complete chain of custody instantly satisfies audit defensibility and closes the finding without lengthy inquiry.
