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.
