Salesforce is unusually easy to customise. That is a genuine strength of the platform and it is also why so many orgs end up with hundreds of custom fields, overlapping automation and a validation rule nobody remembers writing that blocks a deal at quarter end.
Custom Salesforce solutions are not good or bad in themselves. The useful question is narrower: does this particular customisation remove enough friction to justify owning it for the next five years. This guide is about answering that question well.
What counts as a custom Salesforce solution?
It helps to separate three levels, because the cost of ownership rises sharply as you move down the list.
- Configuration. Custom fields, objects, page layouts, validation rules, reports and permission sets. Built with clicks, upgraded by Salesforce, low ongoing cost.
- Declarative automation. Flow, approval processes and scheduled actions. Still clicks, but now you have logic that can conflict with other logic.
- Code. Apex triggers and classes, Lightning Web Components, custom integrations. Full flexibility and a permanent obligation to test and maintain it.
A reasonable default is to exhaust each level before moving to the next. Most requirements that arrive described as "we need a custom build" turn out to be satisfiable with configuration plus one Flow once somebody asks what the underlying problem is.
When is customisation genuinely worth it?
Three tests cover most cases. If a proposed customisation fails all three, it is usually preference rather than need.
Standard functionality forces a worse process
Sometimes the out-of-the-box path genuinely does not fit how the business works, particularly in regulated or highly specialised industries. Approval chains that depend on deal composition, or pricing logic tied to contract structure, are common legitimate examples.
The manual workaround has a measurable cost
If ten people spend twenty minutes a day on a copy and paste routine, that is roughly 800 hours a year. Automation that takes a week to build repays itself quickly and keeps repaying. Do the arithmetic before the build rather than after.
It is a real competitive difference
A customer portal experience or a pricing engine that genuinely distinguishes you is worth owning. Being slightly particular about how an internal field is laid out is not.
Where customisation goes wrong
The failure pattern is consistent. Nobody makes one bad decision. Instead, twenty individually reasonable decisions accumulate into an org that is expensive to change.
| Pattern | What it looks like later |
|---|---|
| Apex used where Flow would do | Fewer people can maintain it, every change needs a developer |
| Multiple automations on one object | Unpredictable execution order, side effects nobody can trace |
| Custom fields never retired | Page layouts with fields no one has populated in three years |
| Minimal test coverage | Deployments fail, releases become risky events |
| No documentation | Knowledge leaves with the person who built it |
If several of these sound familiar, the productive next step is measurement rather than more building. Our Salesforce org health check checklist gives you a structured way to find out how much debt has accumulated before deciding what to do about it.
How do you keep customisation maintainable?
A handful of practices separate orgs that stay workable from orgs that calcify.
- One automation framework per object. Decide whether Flow or Apex owns a given object and stay consistent. Mixed ownership is where unpredictable behaviour comes from.
- Write the test first for anything in Apex. Salesforce requires coverage anyway. Meaningful assertions rather than coverage padding are what actually protect you at release time.
- Document the why, not the what. Anyone can read a Flow to see what it does. Nobody can reconstruct why the threshold is 5,000 rather than 10,000.
- Review quarterly and delete. Retiring unused fields and automation is real work with real benefit. Schedule it or it never happens.
- Put releases behind a pipeline. Once more than one person builds in the org, informal change control stops working. Our guide to Salesforce DevOps and test automation covers what that pipeline needs to contain.
Which customisations pay off most often?
Across the orgs we work in, a few categories reliably justify themselves while others reliably disappoint. The pattern is not about technical difficulty, it is about how often the thing runs and how much manual judgement it removes.
| Customisation | Typically worth it? | Why |
|---|---|---|
| Automated quote or approval routing | Yes | Runs constantly, removes waiting time from every deal |
| Integration to billing or ERP | Yes | Stops duplicate entry and the errors that come with it |
| Guided screens for complex data entry | Often | Improves data quality at the point of capture |
| Custom reporting dashboards | Sometimes | Valuable if leadership acts on them, wasted if not |
| Rebuilt standard objects | Rarely | You inherit maintenance for something Salesforce already supports |
| Cosmetic layout changes | Rarely | High opinion cost, negligible operational benefit |
A useful heuristic: automation that runs hundreds of times a month almost always repays its build cost, while anything that runs a handful of times a quarter is usually better left as a documented manual step. The exception is work where a mistake is expensive, such as pricing or compliance, where automation earns its place through consistency rather than volume.
What does customisation cost over time?
Teams routinely budget the build and forget everything after it. The build is usually the smaller number across a five-year horizon.
- Three Salesforce releases a year. Each one needs regression testing against your custom code, even when nothing breaks.
- Change requests. Business processes move and custom logic has to move with them.
- Knowledge transfer. Every time someone joins or leaves, undocumented customisation costs time.
- Eventual removal. Retiring a customisation safely takes real effort once other things depend on it.
A reasonable planning assumption is that ongoing ownership costs roughly fifteen to twenty-five per cent of the original build each year. Applying that figure at approval time changes which requests look worthwhile, which is exactly the point.
Custom build or integration?
A regular fork in the road is whether to build functionality inside Salesforce or connect to a system that already does it. Rebuilding inventory management or complex billing inside Salesforce is usually a mistake, because you end up maintaining a second-rate version of a product someone else supports properly.
Integration brings its own decisions about tooling and cost, which we compare in MuleSoft versus custom API integration. The broader question of whether to build at all is worth working through deliberately and our guide on build versus buy sets out a framework for it.
A practical rule
Before approving any custom Salesforce solution, write down three things: the problem in one sentence, the cost of not solving it and who will maintain the result in two years. If the third answer is unclear, the first two rarely matter enough to proceed.
Customisation is a tool, not an achievement. The best orgs we work in are not the most elaborate ones. They are the ones where every custom piece has an obvious reason to exist and somebody who understands it. Restraint early is what keeps the platform fast to change three years later, when the business needs something nobody has thought of yet.
If you are weighing a build or suspect an org has drifted past the point of being comfortably maintainable, our Salesforce team can assess it, or get in touch to talk through a specific requirement before you commit engineering time to it.
