# See what breaks before you change anything in Salesforce.

> SyncOnAI 360 Lineage shows how the parts of a Salesforce org depend on each other. Relationships come from the org's parsed source and Salesforce's own dependency data, so every link can be traced to evidence, and nothing is reported as unused unless the source needed to prove it was actually read.

Source: https://synconai360.com/features/impact-analysis

## Key facts

- **0**: Guessed relationships: every link comes from source
- **6**: Kinds of overlap and duplication detected
- **1**: Question to ask: what breaks if I change this?
- **Plain**: Language first, the technical map behind it

## Why Salesforce changes break things nobody expected

Salesforce's own Where Is This Used button covers part of the picture. Flows reading a field inside a formula, Apex building a query from strings, a report filtering on a picklist value: the dependencies that cause incidents are the ones that do not show up.

- **Field changes ripple quietly.** Renaming a picklist value or changing a field type can stop a Flow from routing, a validation rule from firing or a report from returning rows, and nobody notices until users do.
- **Unused is a guess.** Tools that call a field unused because they found no reference will happily delete something a managed package or an integration depends on.
- **Duplication hides in plain sight.** Two validation rules enforcing the same thing, three Flows on the same trigger, near-identical permission sets: overlap grows one urgent request at a time.
- **Impact analysis takes days.** Before a significant change, someone opens every Flow, class and report by hand. It is slow, it is error-prone, and it rarely gets written down.

## How does SyncOnAI 360 map dependencies in a Salesforce org?

Relationships are parsed from the source SyncOnAI 360 retrieves for each org, Apex, Flows, Lightning components, validation rules and more, and combined with Salesforce's own dependency data. Every link is evidence-based: it exists because something in the source shows it.

Open any component and the Overview tells you, in plain language, what uses it, what it uses and what to watch. Behind it sits a technical map for architects and developers who want to explore further. Components whose source Salesforce hides, such as managed package code, contribute no outgoing links, and the map says so rather than pretending to completeness.

- Relationships parsed from source plus Salesforce's dependency data
- A plain-language overview of every component
- A technical map behind it for deeper exploration
- Hidden package code reported as hidden, not as clean

## How do you know what a change will break?

Ask before you change. Who writes to this field? What does changing this picklist value break? Is this metadata genuinely unused? Does something already solve this requirement? Each of these has its own analysis, and the chat runs them for you when you ask in plain language.

When the change becomes a proposal, its blast radius is calculated from the same relationships: everything else in the org that uses the components being changed. Approvers see it next to the pre-flight checks, so the impact is part of the decision rather than an afterthought.

- Who writes a field, and what changing it affects
- What a picklist value change breaks
- Whether something already solves the requirement
- Blast radius on every proposal, from the same map

## How does SyncOnAI 360 find technical debt and duplication?

The Technical debt lens ranks duplicates, unused metadata and legacy automation for each org. Behind it, detectors look for duplicate validation rules, similar fields, overlapping automation, redundant permission sets, forked Lightning components and scheduled jobs that collide.

Similarity is judged on text and structure, so the results show you what looks alike and why. Whether two things should be merged is a business decision, and the tool leaves it with you.

- Duplicate validation rules and similar fields
- Overlapping automation on the same object
- Redundant permission sets and forked components
- Colliding scheduled jobs

## Can you safely tell if Salesforce metadata is unused?

Only when the evidence supports it. SyncOnAI 360 never concludes that a field, class or Flow is unused from a missing link alone. If the source needed to prove a negative could not be read, the result is reported as unknown, with the reason.

That matters most when you are cleaning up. A list of truly unused fields you can remove with confidence is worth more than a longer list that includes the field a hidden integration writes to every night.

- Unused only when the evidence is complete
- Unknown, with the reason, when it is not
- Cleanup lists you can act on with confidence

## How do you see how a Salesforce org is built?

Dependencies answer what uses what. The Architecture lens answers how the org is built overall: its automation style, its layers, its naming conventions and its sharing model. The Canvas lens draws the data model, so the objects and relationships behind every dependency are visible in one picture.

The Changes lens adds time: what changed in the org and when, and whether it came through SyncOnAI 360 or somewhere else. Together they let an architect read an unfamiliar org in an afternoon rather than a fortnight, and give everyone the same picture to discuss.

- Architecture: automation style, layers, naming and sharing
- Canvas: a map of the data model
- Changes: what moved, when, and through which route

## How lineage works

1. **Connect and sync.** SyncOnAI 360 retrieves the org's configuration and source, including Apex, Flows and components.
2. **Relationships are built.** Source is parsed and combined with Salesforce's dependency data into one map of the org.
3. **Ask about a component.** Open it in Lineage, or ask the chat what uses it and what would break.
4. **Change with the impact in view.** Every proposal shows its blast radius beside the pre-flight checks.

## Impact analysis, with and without SyncOnAI 360

| Without | With SyncOnAI 360 |
|---|---|
| Where Is This Used, and then guesswork | Relationships parsed from the org's own source |
| Days of opening Flows and classes by hand | Ask what uses a component and get the answer with its evidence |
| Unused means nothing referenced it | Unused only when the evidence is complete |
| Duplication found by accident | Overlap and duplication detected and ranked |
| Impact assessed after the incident | Blast radius shown before anyone approves the change |

## Who uses impact analysis

- **Salesforce admins.** Ask what a field change would break, or what writes to a field, before touching it, and get an answer in plain language with the components named.
- **Salesforce developers.** See every class, trigger, Flow and component that depends on what you are changing, and the same blast radius on the proposal before it deploys.
- **Salesforce architects.** Trace how a component connects across automation, code and the data model, with every relationship backed by evidence.
- **Approvers.** Approve with the affected components in front of you, automation and validation first and access grants last.

## Frequently asked questions

### What is Salesforce impact analysis?

Impact analysis finds everything a change will affect before you make it: the Flows, Apex, validation rules, reports and pages that use a field or component. SyncOnAI 360 builds this from the org's parsed source and shows it in plain language.

### How is this different from Salesforce's Where Is This Used?

Where Is This Used covers part of the picture. SyncOnAI 360 parses the source of Apex, Flows and components and combines it with Salesforce's dependency data, so it can follow relationships the standard button does not show.

### Can it tell me if a field is safe to delete?

It tells you whether the evidence shows the field is unused. If the source needed to prove that could not be read, for example managed package code, the answer is unknown, with the reason, rather than a confident yes.

### Does it cover managed packages?

It shows managed package components and what of yours uses them. Code that its publisher hides cannot be read, so it contributes no outgoing relationships, and the map says so.

### Can I ask about dependencies in plain language?

Yes. Ask the chat questions like "What writes to Opportunity.Amount?" or "Change Account.Rating to a picklist. Is that safe?" and it runs the right analysis and shows its sources.

### How does lineage appear when I change something?

Every proposal shows its blast radius: everything else in the org that uses the components being changed. Approvers see it beside the named pre-flight checks.

### Does it find duplicate automation?

Yes. It detects overlapping automation on the same object, duplicate validation rules, similar fields, redundant permission sets, forked components and scheduled jobs that collide.

### Who is lineage for?

Admins get a plain-language overview of any component. Architects and developers get the technical map behind it. Release managers and approvers get the blast radius on every change.

### Can I see the org's data model?

Yes. The Canvas lens inside each org draws its data model, alongside Lineage for individual components and Architecture for how the org is built overall.

### Is impact analysis included on every plan?

Every plan includes every feature. Free covers one user and one production org with its sandboxes, on your own Anthropic or OpenAI key, with no credit card and no time limit. Paid plans include AI and cover more people and production orgs.

### Does impact analysis cover permission sets?

Permission grants make up most relationships in a typical org, so they are left out of the default views to keep the picture readable. Permission-related findings, such as overly broad access, are covered by the org audit.