Horus Eye · Architecture

Your Salesforce org isn’t too big. It may be too interconnected.

Q: What is a god object in Salesforce?

An object that has accreted fields, automation and dependents from several business domains until every change to it touches more than anyone expects. Horus Eye flags one only when it is both a relative outlier — top 5% of the org on fields, automation layers or inbound dependencies — and above absolute floors (150 fields, 5 automation layers, or 40 inbound dependencies).

Q: What makes a Salesforce org too complex?

Not volume — coupling. An org with many components that reference each other narrowly changes easily; a smaller org whose objects sit in dependency cycles, carry several domains, and feed dozens of dependents resists every change. Complexity worth measuring is the shape of the dependency graph, not the size of the metadata list.

Q: How do I audit Salesforce architecture?

Map the dependency graph, find the concentration — which objects carry outlier size and coupling, which loops block clean deployment ordering, which components are pinned to retiring technology — and score change risk per component. Then sequence remediation by leverage rather than by list order.

Q: Is this aligned with Salesforce Well-Architected?

Yes. Where an architecture rule takes a position — least-privilege access, intentional automation, composable design — its references cite Salesforce Well-Architected and Salesforce's architect decision guides, applied to your org's own dependency data.

Metadata volume is rarely the problem — plenty of large orgs change easily. What makes change expensive is coupling: objects that carry five departments’ fields, dependency loops no deploy order can satisfy, one field that everything quietly leans on. This is the architecture risk that hides behind a working Salesforce org — and Horus Eye makes it visible, measures it, and where decomposition is safe, performs it reversibly.

Run an Architecture Assessment What Horus Eye is

Salesforce architecture diagram generated by Horus Eye: one object and the automation, code, layouts and reports that depend on it — **One object, mapped:** a live Salesforce architecture diagram — the automation, code, layouts and reports that depend on it, the picture every change plan should start from.

How coupling announces itself

Symptoms

A “small” field change is scoped at three sprints, and nobody can explain the estimate beyond “last time it broke things.” One object carries fields from sales, service, finance, legal and marketing — forty record types, thirty layouts, and an automation stack in three technologies. Lightning pages still lean on Aura components and Visualforce underneath. A managed package’s namespace is tangled through custom code that was supposed to stay independent. Each of these was a reasonable decision once; together they are why the org resists change.

The dependency graph above is the Salesforce architecture diagram most teams have never seen drawn from their own metadata — not a whiteboard idealization, but the org as it actually references itself. If you have ever hunted for a tool to map Salesforce objects and Flow dependencies, this is that map — generated from the org, not drawn from memory.

The eleven architecture rules — and what they refuse to claim

Evidence, not verdicts

Dependency cycle — critical

A loop in the dependency graph (A depends on B depends on … depends on A) blocks clean deployment ordering, and no component in the loop can change in isolation. Horus walks the loop edge by edge; whether it is intentional stays your call.

Object effectively immutable — critical

Fired when more than 30 distinct components depend on one object: it has become fixed in place by its dependents. Deep coupling is expected for a core object like Account — the rule reports the count and asks whether the object can still be safely modified, never asserts it is wrong.

God object — the outlier hub

Flagged only when top-5% in this org on fields, automation layers or inbound dependencies and above absolute floors (150 / 5 / 40). In orgs under 20 objects the percentile test is skipped — and the evidence says so.

Field centrality — a note about cost

A field an outlier number of components depend on isn’t broken. It is expensive: changing its type or values means moving everything in the list together. The rule also names what it cannot see — reports, list views and API consumers — so the real dependency is “at least this, never smaller.”

Alongside: record-type and layout outliers (each variant multiplies upkeep), Lightning pages on legacy Aura/Visualforce, custom components coupled to a migrating package ecosystem, API-version debt, and fields referenced only by automation that isn’t running — that last one deliberately conservative: one unreadable reference and the field is skipped, because a claim the data cannot support is worse than a missed candidate.

None of this is invented doctrine. Where a rule takes a position — least-privilege access, intentional automation, composable design — its references cite Salesforce Well-Architected and Salesforce’s own architect guidance, so the standard your org is being read against is the one Salesforce publishes, applied to your solution architecture with your org’s own numbers.

A god-object finding in Horus Eye: outlier size and coupling, with the decomposition guidance

Change risk you can put a number on

Blast radius

Deep Read scores change impact per component (0–100) from reach, criticality and activity, and reports it with the affected components by type and by hop, the users affected, and a plain-English statement. That single number is what turns “we should be careful with this object” into a sequencing decision a steering committee can act on.

ILLUSTRATIVE HORUS EYE FINDING · DEMO ORGHIGH

Architecture concentration: four objects carry the majority of structural risk

What Horus Eye detected: A representative architecture where a large share of the org’s severity-weighted exposure concentrates on four objects — each an outlier on fields, automation layers or inbound dependencies.
Evidence: Per-object field counts, automation stacks and inbound dependency counts, ranked against the org’s own distribution; the concentration reported as a share of the whole.
Why it matters: Concentration is leverage: remediating four objects moves more risk than a hundred scattered fixes. It is also fragility — those four are where the next regression lives.
Recommendation: Decompose along domain seams where they exist — extension objects for clusters of fields serving distinct processes — and tighten change control on what stays central.
Confidence: Moderate — concentration computed from observed size and coupling; the pattern is illustrative

Decomposition, done reversibly

The clearing

God-object decomposition is the architecture fix everyone postpones because it feels irreversible. Horus Eye’s version isn’t: the plan creates the extension object, moves the field group, migrates the data and maps the permissions as sanctioned operations — each approved by you, validated with zero writes first, reversible, with dependents respected and the blast radius shown before anything moves. Record-type consolidation runs the same way. What stays manual — the domain judgment of where the seams are — is exactly what Kemisoft’s architects do with you, on Horus Eye’s evidence.

The object workspace in Horus Eye: fields, automation, dependents and findings for one object

Frequently asked questions

Straight answers

How do I audit Salesforce architecture?

Map the dependency graph; find the concentration (outlier objects, cycles, retiring tech); score change risk per component; then sequence by leverage. That order matters — an audit that starts with a metadata inventory usually ends as one.

How can I find Salesforce dependencies?

Salesforce’s dependency API records metadata references, and Horus Eye’s Dependency Explorer reads them across packages — but reports, list views and API consumers are not in that data. Any honest dependency answer is “at least this”; plan changes with that asymmetry in mind.

What makes a Salesforce org too complex?

Coupling, not volume: cycles, multi-domain objects, high-fan-in fields, and automation spread across technologies. Two orgs of identical size can sit at opposite ends of changeability.

How do I reduce architecture complexity?

Extract along seams: clusters of fields and automation that serve one process are candidates for extension objects; shared logic inside a dependency loop usually wants its own component. Do it with the blast radius visible, one reversible step at a time.

What is a god object in Salesforce?

An object that became an outlier-sized hub — in Horus Eye’s terms, top-5% in your org on fields, automation layers or inbound dependencies and above absolute floors. Some domains legitimately centralize; the finding is a structural observation to review, not a design verdict.

Is this aligned with Salesforce Well-Architected?

Yes — where an architecture rule takes a position, its references cite Salesforce Well-Architected and Salesforce’s architect decision guides. An assessment here is an org check against Salesforce’s published standard, evidenced with your org’s own dependency data — not a consultant’s private opinion of good design.

Protected AI — the Trust Layer

Every AI read in Horus Eye is metadata-first: built from an allowlist, sanitized by pattern, made through one audited gateway and checked by an output firewall on the way back — and AI is off by default, per org. Every request carries an audit id and an AI Data Scope manifest you can open.

See the Trust Layer

See your org’s coupling before you plan the next change

One scan maps the dependency graph, names the outlier hubs, and scores the blast radius — the evidence an architecture decision deserves.

Try Horus Eye Run an Architecture Assessment All Horus Eye pages

Keep reading

Horus Eye