No one designs a 300-field Account. It accretes: each department’s “just one field,” each project’s status flags, each integration’s external IDs. Every addition was cheaper than a design conversation — and the sum is an object that five business domains depend on, where every change demands a cross-departmental regression pass.
Why the field count isn’t the real problem
Fields are the visible symptom. The cost lives in what surrounds them: the automation layered on the object, the record types multiplying layouts and picklists, and the inbound dependencies — everything that references the object and breaks when it changes. An object can carry 300 fields harmlessly if nothing couples to it; 120 fields with five automation layers and sixty dependents is the harder problem.
An honest god-object test
Beware absolute thresholds — “more than N fields is bad” flags every org differently sized than the rule’s author’s. A defensible test is relative and floored: an outlier against this org’s own distribution (top 5% on fields, automation layers, or inbound dependencies) and past absolute floors so small orgs don’t flag their biggest-but-fine object. That is the test Horus Eye runs, published thresholds and all — and even then the finding is a structural observation to review, because some domains legitimately centralize.
The way back
Decomposition along seams: clusters of fields and automation that serve one process become extension objects, with data migrated and permissions mapped — reversible steps, dependents respected, blast radius visible before anything moves. The object that remains central then changes deliberately, with an owner — which is all “architecture” ever meant.
Living with a hotspot you cannot redesign yet
Most teams cannot stop and re-architect Account this quarter — and do not need to. The practical regime: put the object on a change diet (every new field states its owner, its purpose in the description, and the report or process that will read it — no reader, no field); run a yearly usage review where fields nobody populated in twelve months are moved off layouts and onto the deprecation path; and require a dependency look before edits, because on a hotspot the question is never “is this field change safe” but “safe for which of the sixty things that touch this object.” None of this shrinks the object this month. All of it stops the compounding, which is the actual emergency.
The bottom line
Treat the hotspot score as a conversation starter with evidence attached, not a grade to be ashamed of. Some domains legitimately centralize on Account; the failure is not the number but nobody owning it. Put a name next to the object, a cadence next to the review, and a dependency check next to every change — and the three-hundred-field object becomes a managed asset instead of a standing hazard. The orgs that struggle are not the ones with big objects; they are the ones where nobody can say who decided anything about them.
