Role testing and user mapping at scale

A role design proves itself only when real people, holding the new roles, can do their jobs and nothing more. At Contoso's scale (about 1,350 users, 120 business roles, three company codes soon to be four) that proof needs a plan: what is tested at which level, who maps every user to new roles, how mapping errors are caught before go-live, and how the evidence is kept.

Three levels of role testing

Negative tests matter as much as positive ones. A role test that only shows the clerk can post an invoice says nothing about whether the clerk can also change the supplier's bank details. Contoso writes, for each high-risk SoD pair, one test that performs the allowed step and one that attempts the conflicting step and must be refused. Organizational negatives follow the same idea: the 1710 clerk tries to post in company code 1810 and must fail.

Tools for diagnosing failures

When a test fails with an authorization error, testers use the standard tools. SU53 shows the last failed authorization checks for a user, up to 100 checks from the last three hours. The system trace for authorization checks, STAUTHTRACE, records every object, field and value checked while a test is run in another session; ST01 can record authorization checks too. The User Information System compares users and roles and lists users by roles or authorization values. The result of a diagnosis is a decision in the design (should this role have that access?), not an automatic change.

User-to-role mapping

Mapping decides which new business roles each of the 1,350 users gets. It is a business decision dressed as a technical task, and it is the most common source of go-live access problems: a user mapped to the wrong role cannot work, or can do too much. Contoso builds the mapping in three passes. First, a proposal is generated from legacy usage: which new business roles cover what each user actually did in the last 12 months. Second, managers review and correct their team's proposals in a workbook, because usage does not show planned job changes. Third, the corrected mapping is analyzed for SoD at user level and approved by the process owners.

Testing at scale without testing everything

Nobody can test 1,350 users individually. Contoso tests every business role at the business role level, runs UAT with real mapping for the high-impact jobs, verifies critical individuals one by one (the payment run, shipping, period-end close), and reconciles the full mapping mechanically: every user in the approved list has exactly the approved roles in CMQ after each mock load, and the same reconciliation runs in CMP at go-live. Mapping changes after approval go through the access request process, so the approved list never drifts silently.