Access Change Monitoring is a dedicated application inside Elements.cloud, scoped to a selected org model, that lets you continuously watch for permission and access changes in your Salesforce org. The app polls Setup Audit Trail on a schedule you choose, evaluates each change against the policies you have defined, and delivers an alert with full context to the destinations you select.
Designed for Salesforce admins, release managers, and compliance leads, this feature is aimed at teams that need to know what just changed, who changed it, and whether they should be concerned — without scanning Setup Audit Trail manually or waiting for the next quarterly review.
Prerequisites
Enterprise plan with Access Change Monitoring add-on enabled
Connected and synced Salesforce Org for the monitoring target
Elements Managed Package connected to the target Salesforce Org
How to find Access Change Monitoring
You can open Access Change Monitoring from a specific org model. Select your org model and then click the Access Change Monitoring button.
The Access Change Monitoring app opens in a dedicated app shell scoped to the selected org model. Each org model has its own configuration, policies, and alerts.
If your space does not have the Access Change Monitoring license enabled, a paywall is displayed in place of the app. Contact your Elements.cloud representative to enable the add-on.
How Access Change Monitoring works
Access Change Monitoring is built around a four-step processing pipeline that runs continuously after setup:
Poll Setup Audit Trail at the interval you select (5, 30, or 60 minutes).
Normalize entries into change signals — structured records that include who made the change, what was changed, when, and the before/after values where available.
Evaluate each change signal against your active policies to find matches, and compute which users were affected.
Create an alert and deliver it to the destinations configured on the matching policy.
✅ Supported monitoring categories
Access Change Monitoring covers the following categories :
System permissions — grants and revokes of system permissions such as View All Data, Modify All Data, Author Apex, and any other system permission in your metadata dictionary.
Assignment membership — users assigned to or unassigned from Profiles, Permission Sets, and Permission Set Groups.
Object permissions (Object CRUD) — changes to object-level access, including Read, Create, Edit, Delete, View All Records, Modify All Records, and View All Fields.
Field-level security (FLS) — changes to Read and Edit access on individual fields.
Each category supports the same scope filter:
a user filter (any users, or users with matching licenses),
an operation filter (Gained, Lost, or Gained or Lost)
a target list (the specific permissions, objects, fields, or controllers you care about).
Targeted notifications
Notifications in Access Change Monitoring are policy-scoped, not org-scoped. This means each policy carries its own definition of what counts as alert-worthy and where the alert should go.
For each policy, you can configure:
A severity (Low, Medium, High, or Critical) that surfaces on the alert and in the destination message.
A Slack channel as a destination when Slack is connected for the space.
One or more email recipients.
Because policies are evaluated independently, two stakeholders subscribed to the same org model receive only the alerts relevant to their scope. A compliance lead watching admin-grade system permissions will not see Field FLS changes on a sales object, and a release manager watching Account and Opportunity CRUD will not see permission set assignments. This per-policy targeting is what keeps the signal-to-noise ratio high.
Every alert message includes the change type (operation and category), the affected entity and controller, a count of impacted users, and a link back into Elements.cloud to view the full alert record.
Common use cases
Access Change Monitoring is most often configured around the following scenarios:
High-risk system permissions — alert whenever View All Data or Modify All Data is granted on any permission controller, so admin-grade access is reviewed the moment it is expanded.
Sensitive object access — alert when objects storing regulated or commercial-sensitive data (e.g., Account, Opportunity, custom objects holding PII) gain new CRUD access.
Sensitive field access — alert when specific fields flagged as compliance-relevant gain Read or Edit access.
Mass assignment to privileged controllers — alert when users are assigned to the System Administrator profile, or to any permission set known to grant broad data access.
Release governance — alert on any CRUD/FLS expansion on the objects in scope of an upcoming release, so unplanned access drift is caught before deployment.
Coming soon
By the end of summer 2026, the following capabilities are planned for Access Change Monitoring:
Assigned Connected Apps and External Client Apps — a new monitoring category covering grants and revokes of Connected Applications and External Client Applications through permission controllers, as well as changes to application policies. This extends monitoring to the new Salesforce metadata pattern that is replacing Connected Apps.
Governance context on alerts — distinguish planned changes from unexpected ones by correlating each alert with approved release work items, so stakeholders are not concerned by alerts that simply reflect an expected release deployment.
Alerts history table — alerts retained indefinitely in a dedicated history view, with the full context preserved for each entry: the triggered policy, the impacted users, the raw Setup Audit Trail entries that produced the alert, and any associated planned-change work item where governance context is available.
Story and bug creation from alerts — raise a story or bug directly from an alert notification entry to track remediation, and export alerts to CSV for compliance review purposes.
Additional polling and configuration controls are also on the roadmap, including the ability to change the polling interval after setup. Today, the polling interval is selected once during setup and cannot be modified afterwards.