A practitioner’s framework for one of the most expensive decisions nobody treats as a decision.

1. Executive Summary

Every Salesforce programme reaches the same fork, usually several times a sprint: do we configure this with clicks, or customize it with code?

After 16 years in CRM consulting, my honest answer is that the question itself is slightly wrong. It is not a one-time choice between two camps. It is a repeatable decision you make requirement by requirement and the teams that get it right follow a simple discipline: configuration first, customization only when it earns its keep, and a documented reason either way.

This post breaks down what each term actually means, why teams get the balance wrong, a five-question decision gate you can apply tomorrow, and what the evidence says about the cost of choosing badly.

Image 1 - The fork every requirement hits, and the third path most teams miss.

2. Background

Let’s get the definitions straight, because the industry uses these words loosely.

Configuration means shaping Salesforce using its native, declarative tools - no code deployed. Think of page layouts, record types, validation rules, permission sets, sharing rules, record-triggered Flows, approval processes, reports and dashboards

Customization means extending the platform beyond what declarative tools can do - Apex classes and triggers, Lightning Web Components, platform events, REST/SOAP callouts, and custom integrations. It requires developers, version control, test coverage, and a deployment pipeline. In exchange, you get behaviour, the platform simply doesn’t offer out of the box.

Two things make this more interesting than a tidy table:

The line moves. Flow now handles logic that demanded Apex a few releases ago - HTTP callouts, complex branching, screen-based wizards. A decision that was “customization” in 2021 may be “configuration” in 2026. Any framework you adopt has to survive that drift.

Salesforce itself refuses to pick a side. The Well-Architected framework - Salesforce’s own prescriptive guidance for architects - states plainly that healthy solutions are almost always a blend of declarative and programmatic building blocks. Good architecture isn’t loyalty to one toolset; it’s consistency and predictability in how you choose.

Image 2 - The two stacks. The dashed line between them is the entire point: it moves three times a year.

3. Problem Statement

Here’s the uncomfortable pattern I’ve watched repeat across automotive, banking, and insurance clients: teams don’t choose between configuration and customization. They default to whichever skill they have in the room.

A developer-heavy team writes an Apex trigger for something a validation rule could do in ten minutes. An admin-heavy team builds a 47-element record-triggered Flow that recalculates rollups across thousands of records - and then wonders why it hits governor limits at month-end volume.

Both defaults create real cost:

• Over-customization produces code that must be regression-tested against every release, maintained by developers who eventually leave, and untangled whenever Salesforce ships the same capability natively. You end up paying twice - once to build it, once to retire it.

• Over-configuration produces mega-Flows nobody can debug, brittle automation that collapses under bulk data, and declarative sprawl that is somehow harder to maintain than clean Apex would have been.

Let me make this concrete with a composite scenario: a truck manufacturer’s dealer service portal on Experience Cloud. One requirement - “show each dealer a consolidated service summary across all their vehicles”

Example:

· Total vehicles under service.

· Total service visits in selected period.

· Open service cases / work orders.

· Average time to resolution.

· Average cost per service.

This requirement was initially built declaratively. It worked beautifully in UAT with 200 test records. In production, with some dealers owning thousands of vehicles, the automation started failing on data volume. Next step was not to add or fix config but was a targeted piece of asynchronous Apex which stores this data at Dealer level and experience cloud fetches it for that page.

The framework below is what should have run before the first build.

Image 3 - Both extremes are cliffs. Teams don’t jump; they drift, following the skills already in the room.

4. Solution

The fix is boringly procedural, which is exactly why it works. For every non-trivial requirement, run this five-question gate - in order:

Q1. Does the platform already do this? Check standard features and recent release notes before building anything. The most expensive customization is the one Salesforce shipped natively six months ago.

Q2. Can declarative tools meet the requirement - at production volume? Not “does the Flow work in a sandbox with 50 records,” but “does it survive a bulk data load of 10,000?” Flows have real execution limits; test against realistic volume before committing.

Q3. Does the logic involve complex integration, heavy computation, or asynchronous processing? Callouts with retry logic, batch processing over large datasets, queueable chains - this is Apex territory. Forcing it into clicks is how mega-Flows are born.

Q4. Who will maintain this in three years? If your admin team will own it, bias declarative. If a development team with CI/CD owns the org, well-structured Apex may genuinely be cheaper to maintain than a sprawling Flow. Maintainability follows the team, not the tool.

Q5. Is the requirement stable, or still evolving? Volatile requirements favors configuration - cheap to change. Stable, complex, high-volume requirements can justify the upfront cost of code.

Only when Q1 and Q2 fail - or Q3 clearly fires - should customization enter the picture. And when it does, write down why. A one-paragraph decision record (“chose Batch Apex because Flow hit element limits at dealer volumes >5,000 vehicles”) saves the next architect weeks of archaeology.

Image 4 - The five-question gate. Screenshot this one and take it to your next design review.

5. Result / Proof

Does the discipline actually pay? Three independent lines of evidence say yes.

Cost and speed asymmetry. Industry analyses consistently find configuration significantly cheaper and faster than custom development - no developer hires, no test-class overhead, no deployment pipeline for simple changes. Salesforce Ben’s comparison notes that configuration typically needs only admin skills and minor Setup-level adjustments, while customization demands dedicated developers plus ongoing maintenance budget.

The fit-gap heuristic. Rule of thumb: if the platform natively covers roughly 90% or more of your needs, configuration alone usually suffices; between about 80–90%, a blend of AppExchange and targeted custom work closes the gap; below ~80%, you should honestly re-examine whether you’re on the right platform at all - because bridging that large a gap with custom code approaches the cost of bespoke software while you keep paying licence fees.

The vendor’s own guidance. Salesforce’s Well-Architected framework and its automation guidance are explicit: good architecture is not about picking one toolset, but about consistent, predictable approaches your team can develop, test, deploy, and maintain. When the vendor that profits from both paths tells you the answer is a governed mix, believe them.

And from the composite dealer-portal scenario: replatforming the volume-sensitive summary logic from declarative automation to asynchronous Apex eliminated the recurring limit failures, while the surrounding 80% of the portal - layouts, permissions, standard components - stayed happily declarative. The lesson wasn’t “code wins.” It was “code won that specific battle, and configuration won the war.”

Image 5 - The fit-gap spectrum. Heuristic thresholds, but far better than deciding by gut feel.

6. Outcome

Teams that adopt the gate see the difference within two or three release cycles:

• Faster delivery on the 80%. Routine requirements ship at admin speed instead of queueing behind a dev backlog.

• Safer releases. Less custom code means less regression surface every time Salesforce ships an update.

• A healthier org. Custom code concentrates where it delivers unique value - integrations, volume processing, differentiated UX - instead of leaking into places a validation rule could live.

•           Better conversations. “Configure vs customize” stops being a turf war between admins and developers and becomes a shared checklist with documented answers.

The strategic outcome is subtler but bigger: your org stays adaptable. Every release, some of yesterday’s code becomes today’s clicks - and a team with decision records can spot those retirement opportunities instead of maintaining Apex forever.

Image 6 - Conceptual, not measured data. The compounding mechanism it illustrates is real: every line of custom code is a recurring maintenance liability, not a one-time cost.

7. Learning

Seven things I would want every architect and decision-maker to take away:

1.“Can” is not “should.” The platform lets you build almost anything either way. That’s a trap, not a feature.

2. Configuration first is a default, not a dogma. It’s a starting bias you override with evidence, never with preference.

3. Test declarative solutions at production volume, early. Most “we need Apex” discoveries happen in production. They should happen in a sandbox with realistic data.

4. Maintainability follows the team, not the tool. A clean Apex class owned by a real dev team beats a 50-element Flow owned by nobody.

5. The boundary moves every release. Re-run the decision periodically; last year’s justified customization may be this year’s standard feature.

6. Document every “customize” decision in one paragraph. Future-you will call it the highest-ROI documentation in the org.

7. The binary framing is the real enemy. The question is never whether to customize - it’s where customization earns its place in a predominantly configured org.

If your team is fighting this battle right now, start small: pick your next three requirements and run them through the five-question gate together - admin and developer in the same room. The framework matters less than the habit.

What’s the worst over-customization (or over-configuration) you’ve inherited? I’d genuinely like to hear the war stories in the comments.