# Know what changed in Salesforce, when, and which way it came in. > SyncOnAI 360 Change History records what changed in each connected Salesforce org and when, and whether the change came through SyncOnAI 360 or another route. Changes made through it keep a full before and after with the request, checks and approver; changes made elsewhere are detected on sync and production changes outside the pipeline are flagged by the audit. Source: https://synconai360.com/features/change-history ## Key facts - **2**: Routes told apart: through 360, or elsewhere - **Full**: Before and after for every change made through 360 - **30d**: Of Setup Audit Trail read into each audit - **1**: Record per sync, plus one entry per changed component ## Why "who changed that?" is so hard to answer in Salesforce Salesforce records some changes in the Setup Audit Trail, in terse entries that are hard to search. Deploy tools record their own deploys. Neither tells you the whole story, and neither can say what changed outside the process. - **Fragmented records.** Deploy logs, the Setup Audit Trail and people's memories each hold part of the history. - **Side doors.** A quick fix made directly in production never appears in the release record. - **No before and after.** Knowing that something changed is not the same as knowing what it was before. - **Audits and incidents stall.** Without a clear history, every post-mortem and compliance review starts with archaeology. ## How does SyncOnAI 360 track Salesforce metadata changes? Each sync records one snapshot of the org plus one entry for each component that genuinely changed, so the history grows with real change rather than with the size of the org. The Changes lens shows what changed and when, and whether it came from SyncOnAI 360 or from somewhere else. History records that a component changed and when, not a copy of its content. For what the old version looked like, changes made through SyncOnAI 360 keep their full before and after on the proposal and the deploy record. History starts when recording starts; it cannot reconstruct an org's past before it was connected. - One snapshot per sync, one row per real change - Route of each change shown - Full before and after for changes through 360 ## How do you catch changes made outside the release process? Every audit reads the last thirty days of the org's Setup Audit Trail. The change intelligence checks flag production changes made outside the deploy pipeline, validation rules that were recently deactivated, and a single user making an unusually high number of changes. Because those checks run after every refresh, a side-door change shows up as a finding with its evidence, rather than being discovered when the next deploy overwrites it. - Production changes outside the pipeline - Recently deactivated validation rules - Unusually high change velocity by one user ## What is recorded for changes made through SyncOnAI 360? Every proposal keeps a before and after view of each file, its named pre-flight checks and its blast radius. Every deploy leaves a receipt: what changed, the request that produced it, the checks, who approved it and when, with rollback to the recorded previous version. Workspace actions, deploys, org refreshes, settings changes and connections, are written to the activity log, so the history covers who did what in the workspace as well as what changed in the org. - Before and after per file - Receipts with request, checks and approver - Workspace activity log ## Can you compare Salesforce orgs or points in time? Yes. Compare metadata between two orgs, such as a sandbox and production before a release, or between snapshots of the same org, to see exactly which components differ. Review history keeps every health review, so scores and findings can be compared over time and the effect of a cleanup or a release can be shown rather than asserted. - Compare between orgs - Compare between snapshots - Health reviews kept for trend ## How does change history support an audit or a client review? When an auditor or a client asks what changed during a period, the Changes lens, the deploy receipts and the activity log answer together: what moved in the org, which changes came through an approved proposal, and who did what in the workspace. Changes that arrived some other way are visible as such, and the change intelligence checks raise them as findings, so gaps in the process are visible as well as the work. - Org changes, receipts and activity together - Side-door changes raised as findings ## How change history builds up 1. **Connect.** Recording starts with the first sync. 2. **Sync.** Each sync records the components that genuinely changed. 3. **Audit.** Changes outside the pipeline are flagged from the Setup Audit Trail. 4. **Deploy.** Changes through 360 keep full before and after on their receipts. ## Change history, with and without SyncOnAI 360 | Without | With SyncOnAI 360 | |---|---| | Terse Setup Audit Trail entries | Changes per component with their route | | Side-door changes go unnoticed | Production changes outside the pipeline flagged | | No before and after | Full before and after for changes through 360 | | Health trend by memory | Every review kept for comparison | | Post-mortems start with archaeology | Receipts and history ready to read | ## Who uses change history - **Salesforce admins.** See what changed in each org since the last release, and whether it came through SyncOnAI 360 or straight in Setup, without reading the Setup Audit Trail line by line. - **Release and delivery leads.** Compare a sandbox with production before a release to see which components differ, and catch side-door production changes before the next deploy overwrites them. - **Compliance and platform owners.** Answer who changed what, when and with whose approval from receipts and the activity log, and see changes made outside the release process as findings with their evidence. - **Consultancies.** Show a client what moved between two reviews, scores and findings side by side, so the effect of the work is demonstrated rather than claimed. ## Frequently asked questions ### How does SyncOnAI 360 know a change happened? Each sync compares the org's components and records those that genuinely changed. Changes made through SyncOnAI 360 are recorded at deploy time with full detail. ### Can it show the previous version of a component? For changes made through SyncOnAI 360, yes: proposals and deploy receipts keep the before and after. For changes made elsewhere, history records when a component changed, not its old content. ### Does it read the Setup Audit Trail? Yes. Each audit reads the last thirty days, and change intelligence checks flag production changes made outside the pipeline. ### Can it reconstruct history before we connected? No. History starts when recording starts. ### Can we compare a sandbox with production? Yes. Metadata can be compared between orgs or between snapshots of the same org. ### Is history kept forever? No. Retention is enforced, and old history is pruned on a schedule. ### Is change history on every plan? Yes. Every plan includes every feature. ### Who can see the history? Members of the workspace. Health reports and audits can also be shared as read-only links.