# Design Salesforce from the org as it really is. > SyncOnAI 360 for Salesforce architects is architecture tooling built on the real org. It describes how each connected org is built, maps dependencies from parsed source, draws the data model, ranks technical debt and duplication, and enforces design decisions through validated, approved changes with a recorded blast radius. Source: https://synconai360.com/solutions/salesforce-architects ## Key facts - **1**: Evidence-based dependency graph per org - **6**: Kinds of overlap and duplication detected - **55**: Audit checks across 12 sections - **0**: Inferred relationships: every link traced to source ## Why Salesforce architecture drifts from the design Architects design in diagrams, and orgs change one request at a time. A year later the org and the diagram describe two different systems, and the next design starts from the wrong one. - **Diagrams go stale.** The architecture document was accurate on the day it was written. The org has had hundreds of changes since. - **Patterns erode.** A trigger framework, a naming convention, a sharing model: each is agreed once and broken quietly by changes nobody reviewed against it. - **Debt without a map.** Everyone knows the org has duplicated automation and unused fields. Nobody can say where, how much, or what removing it would affect. - **Reviews without the org.** Design reviews discuss intent. The question that matters, what this change will actually touch, needs the real org to answer. ## How do you assess how a Salesforce org is built? The Architecture lens describes each org as built: its automation style, its layers, its naming conventions and its sharing model. The Canvas lens draws the data model. Together they give an architect a current picture in an afternoon instead of a fortnight of interviews. The audit adds 55 checks across twelve scored sections, including automation, permissions and security, Apex, limits and packages, with evidence for every finding and a letter grade for the org. - Automation style, layers, naming and sharing - Data model canvas - Audit across twelve scored sections ## How does SyncOnAI 360 map Salesforce dependencies? One dependency graph per org, built from parsed source and Salesforce's own dependency data, with no inferred or fabricated links: every relationship traces to a source artefact. Components whose source Salesforce hides contribute no outgoing links, and the map is honest about it. Lineage presents any component in plain language with the technical map behind it. Permission grants, which make up most relationships in a typical org, are left out of default views so the structure that matters stays readable. - Every link traced to source - Hidden package code reported honestly - Plain language for reviews, technical map for depth ## How do you find and prioritise Salesforce technical debt? Detectors find duplicate validation rules, similar fields, overlapping automation on the same object, redundant permission sets, forked Lightning components and scheduled jobs that collide. The Technical debt lens ranks duplicates, unused metadata and legacy automation per org. Similarity is judged on text and structure, so results show what looks alike and why; whether to merge is a design decision left with you. Nothing is called unused unless the evidence to prove it was read. - Six detectors for overlap and duplication - Debt ranked per org - Unused only with complete evidence ## How do architects keep changes in line with the design? Every change is a proposal with named pre-flight checks, a before and after view and its blast radius, validated against the target org before anyone approves it. Production needs an admin other than the author, and the deploy policy adds freeze windows and required approvers. Design decisions and standards live in Pages beside the org, searchable from the Knowledge Hub and from the chat, so the AI and the team see the same conventions when they build. - Blast radius in every review - Required approvers and freeze windows - Standards in Pages, visible to the AI and the team ## How do teams keep the AI and each other consistent? Org rules set what the AI must respect in each org: naming conventions, forbidden patterns and the preferred type of automation. Every change the chat or an agent drafts is built inside those rules, so a team's conventions apply to AI-built work as well as their own. Agents can also suggest something worth remembering, such as a convention they noticed, but nothing is remembered until a person approves it, and memories never cross into another workspace. Standards and decisions recorded in Pages are searchable by everyone, including the AI. - Per-org naming conventions and forbidden patterns - A preferred automation type the AI follows - Memories saved only with approval ## An architecture review with SyncOnAI 360 1. **Read the org.** Architecture, data model and dependency graph from the first sync. 2. **Measure.** Audit sections, health and ranked technical debt. 3. **Decide.** Record the target design and standards in Pages. 4. **Plan.** Turn findings into work items and a roadmap. 5. **Enforce.** Review every change with its blast radius, approved by a second admin. ## Architecture, documented versus grounded | Without | With SyncOnAI 360 | |---|---| | Diagrams that go stale | Architecture read from the org on every sync | | Dependencies traced by hand | An evidence-based graph per org | | Debt known but unmeasured | Duplication and debt detected and ranked | | Reviews on intent alone | Reviews with the blast radius in the org | | Standards in a forgotten document | Standards beside the org, visible to the AI | ## Frequently asked questions ### What does SyncOnAI 360 offer Salesforce architects? A current, evidence-based view of each org: architecture analysis, a dependency graph from parsed source, a data model canvas, audit sections, ranked technical debt, and governed change with blast radius. ### Are dependencies inferred? No. Every relationship traces to source or to Salesforce's own dependency data. Nothing is fabricated or guessed. ### Can we see the data model? Yes. The Canvas lens draws each org's data model. ### How is duplication detected? By text and structure: duplicate validation rules, similar fields, overlapping automation, redundant permission sets, forked components and colliding scheduled jobs. ### Can we compare orgs? Each org has its own architecture, health and audit, viewed side by side in the Command Center, and metadata can be compared between orgs. ### Can we enforce design standards? Every change is reviewed as a proposal with checks and blast radius, approved by a second admin. Standards recorded in Pages are visible to the team and the AI when they build. ### Does it handle large orgs? Yes. Large orgs take longer on the first sync, and later syncs fetch only what changed. Permission grants are left out of default views to keep large graphs readable. ### Is it suitable for enterprise architecture reviews? Yes, for the Salesforce estate: every org's architecture, debt and dependencies from evidence, with read-only reports you can share. ### Can we codify architectural rules for the AI? Yes. Org rules set naming conventions, forbidden patterns and the preferred automation type per org, and AI-drafted changes are built inside them. ### Can we see what changed since the last review? Yes. The Changes lens shows what changed in the org and when, and whether it came through SyncOnAI 360 or somewhere else. ### Does it show the order of execution on an object? Yes. For any record-triggered Flow, the builder lists everything that runs when the record is saved, in Salesforce's order of execution: before-save Flows, validation rules, Apex triggers and after-save Flows. ### Can findings feed an architecture roadmap? Yes. Audit findings and technical debt become work items in one step, which can be planned on a project roadmap and grouped into releases. ### Is architecture analysis included on every plan? Yes. Every plan includes every feature. Plans differ in users, production orgs and whether AI is included. ### Can our own AI tools read the architecture? Yes. Claude Desktop, Cursor and other MCP clients can read connected orgs through a read-only, scoped and logged connection, including metadata search and dependency lookups for any component.