Dynamics 365 CRM Security and Role UAT: What to Test Before Go-Live

Dynamics 365 CRM security is not proven by reading the role configuration. Effective access is the result of security roles, business units, teams, ownership, sharing, hierarchy, Azure AD group membership, and the record being opened. A user can have the right role and still see the wrong data—or be blocked from the record needed to complete a sale.

Security UAT should therefore use real personas and representative records. Test the actions users take, the information they rely on, and the boundaries they must not cross. The goal is not only least privilege; it is a usable access model that survives the first organisational change after go-live.

1. Build a persona and record-access matrix

Start with the business roles that will operate CRM, not the roles listed in the solution design. Include sales representatives, sales managers, service agents, executives, finance users, integration accounts, and administrators where relevant.

• —Record visibility for owned, team-owned, parent-business-unit, child-business-unit, and unrelated records.
• —Actions each persona must perform: create, qualify, edit, assign, share, approve, close, export, and report.
• —Fields and related records that should be visible, read-only, editable, or completely hidden.
• —Dashboards, views, queues, charts, advanced finds, exports, mobile access, and API outcomes.
• —Expected access after a user joins, leaves, or moves between Azure AD groups and business units.

2. Test the effective role combination

A user rarely has one role. Test the combination that comes from direct assignment, teams, business units, hierarchy, and Azure AD group mappings. Look for both privilege gaps and privilege escalation.

• —A sales user can complete the lead-to-opportunity journey without seeing another territory's confidential records.
• —A manager can review team performance and approve the intended actions without gaining broad edit or export access.
• —A finance or integration role exposes only the entities and fields required for its process.
• —Two individually acceptable roles do not combine into unrestricted access to customer, pricing, or financial information.
• —A queue or team assignment does not accidentally make every record in that queue visible to every team member.

3. Exercise business-unit and hierarchy boundaries

Use records that sit on the boundaries of the organisational model. Include a parent unit, sibling units, child units, territories, shared accounts, and records transferred between owners.

• —Confirm parent-unit managers see the intended roll-up while unrelated units remain isolated.
• —Transfer an account or opportunity between business units and verify ownership, visibility, reporting, and audit history.
• —Share a record temporarily, then remove the share and confirm access ends at the right time.
• —Test territory reassignment and manager changes without leaving records visible to the previous team.

4. Validate field security and sensitive data

Record access is only one layer. Test sensitive fields, related entities, notes, attachments, reports, search, exports, and integrations. A user who cannot open a form may still be able to discover or export information through another route.

• —Read-only and hidden fields across forms, views, quick find, advanced search, dashboards, and exports.
• —Notes, attachments, audit history, customer pricing, forecasts, and finance-related values.
• —Mobile and offline behaviour for users who work away from the office.
• —Service accounts and Power Platform connections using minimum required permissions.

5. Rehearse joiner, mover, and leaver changes

Role design is only safe if the operating process keeps it safe. Test the identity lifecycle that changes CRM access, including delays, conflicting groups, inactive accounts, delegated users, and emergency removal.

“A Dynamics 365 security model is ready when the right user can complete the right process, the wrong user cannot see the wrong record, and both outcomes remain true after the organisation changes.”