The Alerts table is the single place in Access change monitoring to see every detected access change: who changed access, what exactly changed, and how significant it is. This article covers how to use it as an audit surface — scoping the data to the question you're answering, exporting it as evidence, and turning anything that needs action into a tracked Story.
It assumes Access change monitoring has already been configured and that at least one policy is active and generating alerts.
For the day-to-day triage workflow, see Using the Access change monitoring tool.
Prerequisites
Enterprise plan with Access change monitoring add-on enabled
Connected and synced Salesforce Org for the monitoring target
At least one active policy so that changes are being detected and recorded
The Alerts table overview
Every detected change appears as a row, with the key context on one line:
Detected at — the timestamp of when the change actually happened, shown in your local time zone
Performed by — who made the change
Controller name — the profile, permission set, or permission set group the change came through
Users — how many users were affected
Operation — whether access was Gained or Lost
Access — what specifically happened (assigned, unassigned, create/read/edit, enabled, etc.)
Category — Assignment, Object, System Permission, or Field
Entity — the specific thing access applies to (e.g. ModifyAllData, ViewAllData, or an object such as Account)
Severity — based on the policy that fired
Policy — the name of the policy that fired
Filter and sort: scope your audit
The whole table is filterable and sortable by every column. Before doing anything else, narrow the data down to exactly what your audit needs to answer. A few common examples:
All Critical severity changes over a given period
Every change on the System Administrator profile (filter Controller name)
All Gained operations on an object holding sensitive data (filter Operation and Entity)
Everything Performed by a specific user during an investigation window
Filtering and sorting also set up the export in the next step — the file reflects what you've narrowed the table down to.
Export to CSV for audit evidence
Export returns the filtered dataset, not the whole table — what you see is what you get. This makes each export suitable as an audit artifact for a specific question or time window, rather than a full data dump you then have to trim.
The Users column in the table shows only a count. To get the actual list of affected users and their accounts, export to CSV: the file includes the full user list for each alert.
From alerts to action: create a story
When an audit surfaces a change that needs to be acted on, you act on it by creating a Story from the Alerts table. Rows are selectable, and from a selection you can:
Add the alerts to an existing Story
Create one new Story from the whole selection
Create a Story per alert
Typical reasons to create a Story from an audit:
Revert a change: the change is unauthorized, unintended, or breaks the org's access policy, and the Story tracks the work of undoing it in Salesforce.
Investigate a change: you can't yet tell whether the change is legitimate, so the Story assigns someone to look into it before a decision is made.
What gets linked is metadata, not the alert. Creating a Story links the related metadata: the permission controller and the entity the change applies to rather than the alert itself.