Conflicts — Proven
The Conflicts — Proven screen keeps only the SoD rows where the activity log proves the user actually exercised both incompatible activities. The view intersects the Details set with SECURITY_ACTIVITY_LOG through the cross-reference table that maps each SoD object to the source-system tables it touches.
A row here is no longer a theoretical conflict — it is a fact, with database traces on both sides.
At a glance
Goal of the view
The proven-conflicts list answers one question: which conflicts are not just theoretical?
- Audit priority. Proven conflicts come first in every remediation plan — they are documented behaviour, not a hypothetical capability.
- Evidence-driven cleanup. Each row has database-level evidence on both sides via the cross-reference table — useful when a user disputes the finding.
- Smaller list, sharper conversation. A few dozen proven rows are easier to discuss with a business owner than the few hundred theoretical rows of Details.
Columns
Same shape as Conflicts — Details (the dataset is a strict subset). Refer to that page for the per-column documentation. The only difference is the filter logic — proven rows are limited to users with activity log evidence on both sides of the conflict, joined via SECURITY_XREF and SECURITY_ACTIVITY_LOG.
Tips & best practices
- Start every quarterly SoD review here. Proven rows are the entries you absolutely need to remediate before reporting.
- Cross-reference with the Activity log to retrieve the timestamps and transaction counts behind each entry.
- A user appearing on both Details and Proven for the same risk is the most urgent case — they have the right and they exercised it. Document the compensating control or revoke.
- A user on Details but not on Proven is a latent risk — capability without usage. Still worth cleaning, lower priority.