# A map of your Salesforce org where every line is evidence. > The SyncOnAI 360 Dependency Graph records how the components of a Salesforce org depend on each other. Relationships are parsed from retrieved source and combined with Salesforce's dependency data, every edge traces to a source artefact, and the same graph drives lineage, impact analysis, blast radius on proposals and unused-metadata detection. Source: https://synconai360.com/features/dependency-graph ## Key facts - **1**: Relationship layer per org, used by every view - **0**: Inferred or fabricated edges - **2**: Sources: parsed code and Salesforce's dependency data - **12**: Affected components named on a proposal, most important first ## Why most Salesforce dependency maps cannot be trusted A dependency map is only useful if a missing line means a missing dependency. Most maps mix guesses with facts, so a clean result might mean nothing depends on it, or that the tool could not see. - **Guessed links.** Name matching and heuristics produce lines that look right and are not, and nobody can tell which. - **Silent gaps.** Components whose source could not be read simply have no lines, and the map looks complete. - **Too dense to read.** Permission grants outnumber every other relationship, burying the ones that matter. - **One graph per tool.** Impact analysis, cleanup and AI each build their own picture of the org, and they disagree. ## How is a Salesforce dependency graph built from evidence? Relationships come from two places: the parsed source of components SyncOnAI 360 has retrieved, such as Apex, Flows, Lightning components and validation rules, and Salesforce's own dependency data. Every edge is evidence-based, so each one traces back to a source artefact. Components whose source is unavailable, such as managed package code its publisher hides, contribute no outgoing edges. That is reported as honest coverage rather than presented as a complete answer, so a missing line is never mistaken for proof. - Edges from parsed source and Salesforce dependency data - Every edge traceable - Unreadable source reported, not hidden ## How do you read a dependency graph for a large org? Permission grants make up the large majority of edges in a typical org, so they are left out of default views. What remains, automation, code, validation and the data model, is the structure that decides whether a change is safe. Lineage presents any component in plain language first, what uses it, what it uses and what to watch, with the technical map behind it for architects and developers who want the full picture. The Canvas lens draws the data model alongside. - Permission grants excluded by default - Plain-language overview per component - Technical map behind it ## What does the dependency graph drive? It is the single relationship layer of the platform. Impact analysis answers who writes a field and what a picklist change breaks. Every proposal lists the components that reference what it changes, signal types first and access grants last, as its blast radius. Unused-metadata detection only concludes unused when the evidence is complete. The chat uses it to answer dependency questions, and Claude, Cursor and other MCP clients can look up a component and everything that depends on it through the read-only connection. - Impact analysis and field safety - Blast radius on every proposal - Unused detection that does not guess - Dependency lookups for MCP clients ## Can you query the dependency graph in plain language? Yes. Ask the chat "What uses Account.Rating?" or "What writes to Opportunity.Amount?" and it reads the graph, shows the tools it used and lists the components with their relationship. Search a component in the Knowledge Hub and open it straight into its lineage. Answers say how much of the org they were based on, so a negative answer, nothing uses this, can be trusted or questioned for the right reason. - Plain-language dependency questions - Knowledge Hub search into lineage - Coverage stated with answers ## How the graph is built 1. **Sync.** Source for code and automation is retrieved with the org's metadata. 2. **Parse.** References in the source become evidence-based edges. 3. **Combine.** Salesforce's own dependency data fills in what it reports. 4. **Use.** Lineage, impact analysis, blast radius and cleanup all read the same graph. ## Dependency maps, guessed versus evidenced | Without | With SyncOnAI 360 | |---|---| | Lines from name matching | Lines from parsed source and Salesforce data | | Gaps that look like answers | Unreadable source reported honestly | | Permission noise everywhere | Access grants out of default views | | A different map per tool | One relationship layer for everything | | Unused means not referenced | Unused only with complete evidence | ## Who uses the dependency graph - **Salesforce architects.** Trace how automation, code, validation and the data model connect in any org, with every line traceable to the source that proves it and a clear statement of where source could not be read. - **Salesforce admins.** Ask what uses a field or what writes to it before changing it, in plain language, and get the components listed with their relationship rather than a raw diagram. - **Salesforce developers.** Find every class, trigger, Flow and component that references what you are about to change, and see the same list as the blast radius on the proposal before it deploys. - **Reviewers and approvers.** See the components a change affects, automation and validation first and access grants last, so an approval is a decision about real consequences rather than a signature on a file list. ## Frequently asked questions ### What is a Salesforce dependency graph? A map of which components in an org reference which others: fields used by Flows, classes called by triggers, objects in validation rules and so on. SyncOnAI 360 builds one per org from evidence. ### Does it use the Salesforce Dependency API? Yes, alongside relationships parsed from the source of retrieved components. Together they cover more than either alone. ### Are any relationships inferred? No. Every edge traces to a source artefact or to Salesforce's dependency data. Nothing is fabricated. ### What about managed packages? Their components appear, and what of yours uses them is mapped. Hidden package code contributes no outgoing edges, and the graph is honest about that. ### Why are permission sets missing from the default view? Permission grants are most of the edges in a typical org. They are left out of default views so the automation and code relationships stay readable. ### How does the graph appear on a proposal? As its blast radius: the components that reference what the proposal changes, with automation and validation listed before access grants. ### Can Claude or Cursor use it? Yes. MCP clients can look up a component and everything that depends on it through a read-only, scoped and logged connection. ### Is the dependency graph included on every plan? Yes. Every plan includes every feature.