How should security teams evaluate access risk when multiple roles are assigned in Dynamics 365 Finance and Operations?

How multiple role assignments change the access review

In Dynamics 365 Finance and Operations, the key question is not what each role allows in isolation, but what the user can do when role assignments are combined. A single role report can understate access risk because it misses privilege stacking, duplicated duties, and paths that only appear once multiple roles are effective at the same time.

This is why reviewers should trace the full hierarchy from role to duty to privilege, then compare the resulting effective permissions with the user’s actual job tasks. If the combined access enables actions outside the role holder’s function, the risk is not theoretical, it is an access design problem that needs remediation.

For teams building a repeatable review process, the most useful baseline is an access governance model that treats roles, entitlements, and recertification as one control surface. NHIMG’s IAM and IGA Basics is a practical starting point because it frames role assignment, access review, and entitlement governance as linked decisions rather than separate checks.

Why combined role evaluation matters in D365FO

D365FO security is layered, so the effective permission set can be broader than any one report suggests. A user may receive a harmless-looking role for one business function and another for operational support, but together those roles can create write access, approval authority, or administrative visibility that no single reviewer would flag on its own.

The practical failure mode is role explosion combined with privilege creep. Over time, users accumulate access for projects, backfills, exceptions, and local fixes, and those assignments are left in place after the original need has passed. That creates an authorization picture that is technically valid in the system but no longer defensible from a business perspective.

Access model design also matters because RBAC alone may not capture every business constraint cleanly. NHIMG’s Authorisation Models Guide is useful here because it helps reviewers distinguish role-based assignment from finer-grained authorization decisions, which is essential when the security question is whether the combined roles still match the person’s duties.

How to test effective access against real work

The most reliable review method is task-based validation. Start with the business activities the user actually performs, then test whether the combined permissions allow only those tasks and nothing materially beyond them. In practice, this means checking not just whether access exists, but whether the user could create, approve, post, reverse, or export records in ways that would exceed their job scope.

Where the user has several roles, look for overlap that changes the risk profile. Two narrow roles can become one broad capability set, especially when one role supplies read access, another supplies transaction rights, and a third supplies approval or administrative functions. The combined effect is what determines whether the account is acceptable.

Teams should also confirm whether any elevated access is temporary, exception-based, or tied to a compensating control. NHIMG’s IAM and IGA Basics supports that review because it connects access certification, least privilege, and separation of duties to the practical question of whether the assigned permissions still fit the user’s function.

Practitioner Guidance

What to prioritise: Review combined permissions first for roles that can create separation-of-duties conflicts, approval bypass, payment impact, or master-data change capability. Those are the assignments most likely to create business harm if they stack unexpectedly.

What to verify: Test the effective access path with a real task list, not a role title list. If the user can complete an end-to-end sensitive workflow without another person’s involvement, the assignment set deserves escalation even if each role looked reasonable on its own.

Common mistake: Treating the role catalog as proof of safety. Role definitions show intended design; they do not prove that the combined assignment set is still aligned to the user’s actual responsibilities.

Practitioner takeaway: In D365FO, access risk is decided by the aggregate permission outcome, not by individual role intent, so the review must end with a business-task test, not a report comparison.

Related resources from NHI Mgmt Group

• How should security teams evaluate S3 bucket access when accounts, roles, and connected services span multiple AWS environments?
• How should NHS security teams reduce privileged access risk without disrupting clinical operations?
• How should security teams govern open finance access across multiple organisations?
• How should security teams run access reviews for ERP systems like Dynamics 365 BC?