Three weeks, one spreadsheet
The quarterly access review starts the way it always does. Someone exports users and their roles from Dynamics 365 F&SCM into Excel, splits the tabs by department, and emails managers with a deadline. Then the chasing begins. Two reminders later, the last approvals trickle in, the spreadsheet is filed for the auditor, and everyone agrees, again, that there must be a better way.
Three weeks of effort. And the uncomfortable question is what it actually proved.
Why the spreadsheet version fails quietly
Managers were asked to certify role names: AP Clerk vNew2, Warehouse Extended, Finance Base Copy. Nobody reviewing that list can see what those roles grant, so the review becomes a plausibility check on job titles. Access that looks reasonable gets approved, indefinitely, without anyone examining its contents.
The data is also stale before the review ends. Roles change during those three weeks; the export does not. Exceptions get resolved in email threads that never make it into the file. And the rationale behind each approval, the one thing an auditor will eventually ask about, is not captured anywhere.
One category deserves special attention. Microsoft’s documentation on role assignment is explicit: “Users who are manually assigned to security roles must also be manually removed by the administrator. These users are not removed from roles by rules for automatic role assignment.” Every manual grant in your environment is therefore a standing review item, sitting there until someone deliberately takes it away.
Five things an F&SCM access review should always cover
A role list per manager is not a review. These five items are where the real risk sits, and each has a place in F&SCM you can check:
- Manual role assignments. Found under System administration > Security > Assign users to roles. Automatic rules never clean these up, so they need an owner and a reason.
- Exclusions from automatic assignment. Users marked as excluded from a role stay excluded until someone resets the status. Check that each exclusion is still intended.
- Segregation of duties overrides. Every assignment allowed despite an SoD conflict is listed on the Segregation of duties conflicts page with its reason for override. Re-confirm each one, and check the reason still holds.
- Roles that violate SoD rules. The Roles violating segregation of duties report shows which roles break which rules. A clean user review on top of a conflicting role design proves little.
- Critical access. Who can maintain vendors and bank accounts, post payments, change security. Review those users first and in depth, instead of spreading attention evenly across hundreds of harmless rows.
What reviewers actually need
A review is only as good as what the reviewer can see. That means actual granted access per user, both directly assigned and inherited through roles. It means the risky part surfaced first: which users hold Critical Permissions, and where combinations conflict with Segregation of Duties. And it means a way to record each decision that survives longer than an inbox.
What the auditor will sample
Auditors rarely re-perform your whole review. They pick a sample of users and findings and ask three questions: who reviewed this, when, and on what basis was it approved? If the answer lives in a filed spreadsheet with a manager’s initials, the evidence is weak. If each decision carries a reviewer, a timestamp and a rationale, and you can show the access that was actually granted at that moment, the same sample passes in minutes. More on that in Turning F&O security findings into evidence an auditor actually accepts.
The same review, structured
With Authorization Monitoring, the review starts from analysis instead of an export. Critical Permissions are defined once, as research questions about your security objects, each with an impact level of high, medium or low. Conflicts combine Critical Permissions that must stay separated. The analysis shows who holds what, and reviewers work through findings as Agreed, Disagreed or To review, individually or in bulk where that is justified. Reviewer, timestamp and rationale are kept per decision in the review history, and the whole result exports to Excel in a form an audit team can sample.
The three weeks collapse into focused sessions, and the output changes character: from a filed spreadsheet that proves a process happened, to documented decisions that prove access was actually reviewed.
If your next access review starts with an Excel export, we should talk. Request a demo and see the same review run on a realistic F&SCM environment.
