# How to know what a Salesforce change will break, before you make it. > Checking the impact of a Salesforce change with SyncOnAI 360 means asking what uses and writes a component, reading its lineage from an evidence-based dependency graph, checking live record counts where data matters, and shipping the change as a proposal that names up to twelve affected components before anyone approves it. Source: https://synconai360.com/use-cases/change-impact-analysis ## Key facts - **12**: Affected components named on a proposal - **0**: Guessed dependencies - **Live**: Record counts when data matters - **6**: Metadata types with cascading checks ## Why Salesforce changes break things nobody expected The Where is this used? button covers some references. Flows, formulas, Apex, components and integrations each hide their own, and a missing reference looks the same as no reference. - **Partial answers.** Built-in usage tools miss references in code and automation. - **Silent gaps.** Unreadable source looks like no dependency at all. - **Data forgotten.** Changing a field affects the records that use it, not only the metadata. - **Approvers in the dark.** The person approving sees files, not consequences. ## How do you find everything that uses a Salesforce field? Ask what uses a field or what writes to it, or open it in Lineage. The answer lists Flows, Apex, validation rules, components and other references, from a dependency graph built from parsed source and Salesforce's own dependency data. Every relationship traces back to evidence, and components whose source could not be read are reported as such, so a short list is never mistaken for a complete one. - Uses and writers listed - Evidence for every link - Unreadable source reported ## How do you check the data impact? Ask how many records use a value or have a field populated, and the query runs live against the org. Records are read live and never stored. That answers the question metadata alone cannot: whether anyone actually relies on what you are about to change. - Live record counts - Never stored - Metadata and data together ## How does impact appear on the change itself? Every proposal runs a cascading dependency check that names up to twelve components referencing what it changes, automation and validation first and access grants last. Fields, Flows, Apex classes and triggers, objects, components and validation rules are covered; for other types the check warns that impact is not available rather than reporting none. A destructive operations check flags field changes that would discard data, and the change is validated against the org before approval. - Blast radius on every proposal - Warnings where impact is unavailable - Data loss flagged ## What if the change still causes a problem? Every deploy leaves a receipt with the version of each component recorded before it, and rollback redeploys those versions. Rollback does not delete components the deploy created and cannot reverse data changes, which is why data impact is checked first. - Receipt for every deploy - Rollback to recorded versions - Limits stated ## How do you check impact across sandboxes and production? Compare metadata between a sandbox and production, or between snapshots of the same org, to see whether the component you are changing differs between environments before you build on it. A change built against a sandbox that has drifted from production is the commonest source of surprises at deploy time; comparing first removes it. - Compare orgs before building - Compare snapshots over time - No drift surprises at deploy ## How to assess a Salesforce change 1. **Ask.** What uses this and what writes to it? 2. **Count.** How many records rely on it? 3. **Draft.** Build the change on a builder or in the chat. 4. **Review.** Read the blast radius and checks on the proposal. 5. **Ship.** Validate, approve and deploy with a receipt. ## Change impact, guessed versus known | Without | With SyncOnAI 360 | |---|---| | Where is this used, partially | Every evidenced reference | | Gaps that look like answers | Unreadable source reported | | Data impact ignored | Live record counts | | Approving files | Approving named consequences | ## Before you change a Salesforce component - [ ] Ask what uses the component and what writes to it. - [ ] Check whether any answer mentions source that could not be read. - [ ] Count the records that depend on the field or value, live. - [ ] Compare the sandbox with production for the components involved. - [ ] Draft the change and any reference updates together. - [ ] Read the blast radius and checks on the proposal before asking for approval. - [ ] Deploy to a sandbox first, then production, and keep the receipt. ## Who checks impact - **Salesforce admins.** Change fields and picklists without breaking automation you did not know about. - **Developers.** Know every caller before changing a class or method. - **Architects.** Plan consolidation with every dependency in view. - **Approvers.** See consequences on the proposal, not just files. ## Frequently asked questions ### Is this the same as Where is this used? It covers more: references parsed from Apex, Flows, components and validation rules, plus Salesforce's dependency data. ### Are any dependencies guessed? No. Every relationship traces to evidence. ### What about managed package code? Hidden package source contributes no relationships, and answers say so. ### Can it count affected records? Yes. Queries run live against the org; records are not stored. ### Which types get cascading checks on proposals? Fields, Flows, Apex classes and triggers, objects, components and validation rules. Others show a warning. ### Why are permission sets listed last? They are most of the references in a typical org and carry less review signal than automation. ### Can Claude or Cursor check impact too? Yes, read-only, through the MCP connection. ### Is impact analysis on every plan? Yes. Every plan includes every feature. ### Can we compare a sandbox with production first? Yes. Metadata can be compared between orgs or between snapshots of the same org. ### What does the approver see? Named checks with pass, warn or fail, an overall risk, the policy decision and the affected components. ### Can I check impact from the chat? Yes. Ask what uses or writes a component in plain language, and the answer lists each one with its relationship.