Walk into most Salesforce orgs and you will find the same things: fields that nobody uses, flows that nobody documented, automations that nobody dares touch because nobody knows what they do, and a vague organisational agreement that the org is "a bit of a mess" — followed by a collective shrug.
This is not a technology problem. The Salesforce platform is capable of being clean, well-governed, and genuinely useful. The mess is not the platform's fault. It is a people and process failure, and understanding exactly how it happens is the first step to not repeating it.
It almost never starts badly. A fresh org, a clear brief, an excited team. The problem begins about six months in, when the business starts making requests faster than good decisions can be made.
A sales director needs a new field — added quickly, no naming convention discussion, no thought about where it fits in the data model. A customer service manager wants an automation — built in a flow, deployed without documentation, works fine for eight months until someone changes a related field and it starts behaving oddly. A VP wants a dashboard by Friday — built with whatever data is available, whether or not that data is actually clean or meaningful.
Each individual decision is defensible. Taken together, over three years, they produce an org that nobody fully understands and nobody wants to refactor because the risk is too high and the political will is not there.
This is the technical debt accumulation pattern. And in Salesforce orgs, it is almost universal.
1. No system owner with real authority. The single most common cause of org chaos is the absence of someone who has both the technical knowledge and the organisational standing to say no. An admin who can build anything but cannot refuse a bad request is not a system owner — they are an executor. Without someone who can push back on poorly scoped requests, evaluate the downstream impact of changes, and enforce naming conventions and documentation standards, the org drifts.
2. Requirements that arrive as solutions. Business stakeholders say "I need a checkbox on the account that does X." What they mean is "I have a problem — Y — and I think a checkbox would help." An experienced Salesforce professional reframes the request before building anything. An inexperienced one builds the checkbox. The checkbox then lives in the org for five years, half-used, increasingly irrelevant, and impossible to remove because nobody knows what depends on it.
3. Zero documentation culture. Documentation in Salesforce orgs has an unfortunate reputation as overhead — something you do when you have time, which means something you never do. The result is that institutional knowledge lives in people's heads. When those people leave — and they always leave — the knowledge leaves with them. The next person inherits a system they cannot fully understand and is afraid to change.
4. Too many admins, not enough architecture. A business that has had three different admins over five years typically has three different ways of doing the same thing coexisting in the same org. Each admin built in their own style, used their own conventions, and left their work in a state that made sense to them. Orgs need continuity and architectural thinking, not just capable hands.
5. Deployment without governance. Changes pushed directly to production, no sandbox testing, no change management process, no release notes. This one is rarer in mature organisations but extraordinarily common in smaller ones. It produces the most spectacular failures — broken automations on a Monday morning, data quality issues that take weeks to trace, trust in the system that erodes over time.
The honest answer is: it depends on which failure mode you're looking at, but leadership carries more responsibility than they typically accept.
Technical problems in Salesforce orgs are often symptoms of organisational problems. When the system owner has no authority, that is a leadership decision. When documentation is not valued, that is a cultural decision set at the top. When every request is urgent and none can be refused, that is a prioritisation failure that originates above the admin or developer level.
The person building the org cannot be held entirely responsible for conditions they do not control. They can advocate for better process. They can document their own work. They can flag risks clearly. But if the organisation does not support those behaviours, the mess will accumulate regardless.
Admins and developers do carry responsibility for their technical choices — naming conventions, whether they take shortcuts, whether they document. These are within their control and matter considerably.
But the framing that orgs are messy because the admin was not good enough is too simple. Usually the org is messy because the organisation treated Salesforce as a tool to be used rather than a system to be governed.
The contrast is stark when you see it. A well-governed org has a clear data model that reflects the actual business, not five years of accumulated workarounds. Fields have consistent naming conventions. Flows are documented — what they do, when they run, who owns them. There is a sandbox environment where changes are tested before they go live. Requests go through a lightweight triage process before they enter the backlog. The system owner has standing to shape requirements, not just execute them.
None of this is technically complex. All of it requires organisational will that most businesses do not allocate until the pain is severe enough to force the conversation.
If you are sitting in a messy org right now, the question you are probably asking is whether to fix it or start from scratch. The honest answer is that starting from scratch is almost never feasible — there is too much data, too much process dependency, too many integrations. You are cleaning the plane while flying it.
The pragmatic approach is incremental governance: stop adding to the mess while systematically reducing it. Establish naming conventions for new work. Document as you go. Remove fields and automations that are demonstrably unused — carefully, with a sandbox first. Build a data dictionary, even a basic one. Each clean-up task is small. The cumulative effect, over six to twelve months, is significant.
The org did not become a mess overnight. It will not become clean overnight either. But it can become progressively less bad — which, in most organisations, is all that is being asked of it.