Four optional files sit alongside a data source's main tables. None is required to run an analysis, and each unlocks a capability that is otherwise unavailable. They work the same way for SAP, generic and Public Cloud sources: drop them in the data source folder, where they are recognized by their header row rather than by filename.
HR data
Adds the organizational dimensions that turn a technical finding into something with an owner.
| Column | Required |
|---|---|
User ID | Yes |
Full Name | Yes |
Department | Yes |
HR Function | Yes |
Location | Yes |
Additional Scope | Optional |
All five required columns must be present. Additional Scope is your own dimension for anything the standard four do not express: legal entity, division, or an audit population defined outside the ERP system. Its values become selectable under Additional Scopes in the analysis criteria.
Once loaded, these fields are available three times over: as analysis scope criteria, as columns in the results table, and as columns in the exported summary report. They are also what the AI Assistant aggregates on. See Scoping Your Analysis.
User canonical mapping
Links per-system accounts to one person, which is the prerequisite for cross-system analysis.
| Column | Meaning |
|---|---|
User ID | The account name in this system |
Canonical Name | The identity that account belongs to |
The file must contain exactly these two columns. A third column prevents it being recognized.
Supply one on each data source, mapping that system's local accounts to a shared canonical name. An account with no mapping row is treated as its own canonical identity, so partial mapping is valid: map the people you care about and leave the rest.
Risk exclusions
Removes formally accepted user and risk combinations from results, so a signed-off exception stops reappearing as a finding every quarter.
Two tables, each with exactly two columns:
| Table | Columns |
|---|---|
| User risk exclusion | User ID, Risk |
| Role risk exclusion | Role, Risk |
One row per accepted combination. Exclusions apply when Risk exclusions is set in the analysis criteria, so they are opt-in per run rather than silently applied. That matters for audit: a run with exclusions and a run without are both available, and the analysis log records which was used.
Organizational scope
Binds the organizational placeholders a ruleset declares, for example $BUKRS, to concrete values.
| Column | Meaning |
|---|---|
Scope | The placeholder name used in the ruleset |
Value From | Start of the value range, * for any |
Value To | End of the range, empty for a single value |
Description | What this scope represents |
Comment | Free text for review notes |
This file is named ORGANISATIONAL_SCOPE.csv and is semicolon-delimited, unlike the other supplementary files whose delimiter is detected. It is written automatically when you set organizational scopes in the interface and click Run analysis, so the usual workflow is to configure once in the application and then edit the file directly for later runs.
A placeholder binding is not a filter. A filter removes rows from a result; a binding changes what counts as a risk, so a conflict is reported only where both conflicting functions are exercisable within the same organizational scope. See Scoping Your Analysis.
Where they go
All four live in the data source folder next to the main tables. For a remote SAP connection, they sit in the folder configured for the connection's downloaded data.
Because detection is by header content, a file whose headers do not match exactly is silently not picked up rather than reported as an error. After adding one, check the Info tab for the data source and confirm the table appears with a row count. See Managing Data Sources.