The same system produces very different answers depending on the angle you take. Scoping is what turns a 40,000-line conflict list into a result somebody can act on, so it is worth setting deliberately rather than running everything and filtering afterwards.
Analysis criteria fall into four families that combine freely.
1. User master data scope
Available on any data source, with no extra files.
| Criterion | Typical use |
|---|---|
| User types | Restrict to Dialog users so technical accounts do not dominate the critical-access findings |
| User groups | Scope to the SAP user group that maps to a team or a support model |
| Users | Test a named population, for example the users an auditor sampled |
| Single roles / Composite roles | Scope to the users holding a role you are redesigning |
| Business roles | Scope to the users holding an IAM business role, when IAM analysis is enabled |
2. HR-based scope
Scope by who someone is in the organization rather than by what their user ID looks like. This requires an HR_DATA file on the data source.
| Criterion | Typical use |
|---|---|
| Departments | Give each department head only their own conflicts |
| Functions | Scope to an HR function such as Strategic Sourcing across departments |
| Locations | Scope to a site or country for a local review |
| Additional Scopes | Your own scope column, for anything the four standard fields do not express |
HR scoping is what turns a technical finding into an owner. A conflict attached to a department and a location can be routed to someone with the authority to approve the remediation, which is usually the step that stalls a clean-up project.
Supplying HR data
The HR_DATA file must contain these columns:
User ID, Full Name, Department, HR Function, Location
An Additional Scope column is optional. When present, its values become selectable under Additional Scopes, which is the way to scope on a dimension specific to your organization, such as legal entity, division, or an audit population defined outside SAP.
Department, HR function and location are also added as columns to the analysis results, so the same dimensions you scoped on are available for sorting and filtering afterwards.
3. Organizational scope
Available when the active ruleset declares placeholders. Organisational scopes binds those placeholders to concrete values, for example $BUKRS to a company code.
This is a different mechanism from a filter. A filter removes rows from a result. A placeholder binding changes what counts as a risk in the first place, so a conflict is reported only where the two conflicting functions are exercisable within the same organizational scope, instead of anywhere the roles happen to coexist.
Each binding has these fields:
| Field | Meaning |
|---|---|
| Scope | The placeholder name used in the ruleset, for example $BUKRS |
| Value From | Start of the value range, * for any |
| Value To | End of the value range, leave empty for a single value |
| Description | What this scope represents |
| Comment | Free text, for review notes |
Bindings are saved per data source when you click Run analysis, and are stored in ORGANISATIONAL_SCOPE.csv next to the data source. You can prepare that file outside the tool and import it.
4. Audit-driven scope
Scope to what is actually under review, so the evidence matches the audit programme rather than the whole landscape.
| Criterion | Typical use |
|---|---|
| Business processes | Scope to the processes in the audit plan |
| Risks | Scope to the specific risk IDs being tested |
| Risk owners | Produce the working list for one risk owner |
| Risk types | Separate SoD conflicts from critical access, so they can go to different teams |
| Risk levels | Restrict a first pass to Critical and High |
| Risk exclusions | Leave out user and risk combinations that have been formally accepted, so they do not reappear as findings |
Users mode or roles mode
The Mode setting changes the question more than any filter does.
- Users analysis shows conflicts as they exist today, created by the combination of roles a person holds. Use it for clean-up, certification and audit evidence.
- Roles analysis shows conflicts built into role design, independent of who holds the role. Use it when deciding whether to fix the role or the assignment. A conflict that appears in roles mode will keep coming back through provisioning until the role itself is corrected.
Worked example
To give the Finance director in France their own remediation list for the risks in this year's audit:
- Mode: users analysis
- User types: Dialog
- Departments: Finance
- Locations: France
- Business processes: the processes in the audit plan
- Risk levels: Critical, High
- Did do: on, so the list separates access that is used from access that is merely assigned
- Organisational scopes: bind
$BUKRSto the French company codes, if the ruleset uses that placeholder
The result is a list that one person can own, rather than a landscape-wide export nobody acts on.