Ask most Salesforce teams how customised their org is and you will get a shrug, or a guess pulled from whoever has been there longest. “Pretty custom, I think.” “We’ve got a lot of Apex.” Nobody actually knows, because nobody is measuring it. That is the gap the CEER methodology was built to close, and it deserves to be far better known than it is.

What CEER actually is

CEER — Config, Extend, Enhance, Replace — is a framework for classifying every piece of Salesforce customisation into one of four buckets, based on how far it moves away from the platform’s standard, out-of-the-box behaviour. It was proposed by Salesforce architect Steven Herod, presented at Dreamforce 2019, and later written up in detail by Lennart Svensson at Storebrand, who applied it to measure and track customisation across a real production org (“Using CEER to measure the level of customization in our Salesforce org”, Dreamforce 2019 slides).

The four categories, roughly in order of increasing cost and risk:

  • Config — no-logic setup: field-level security, page layouts, list views, default owners, record types. You are turning on capability the platform already has.
  • Extend — adding logic and data processing on top of standard objects and processes: Flow, validation rules, custom fields, Lightning components, Apex that extends rather than replaces standard behaviour.
  • Enhance — bringing in tooling (native or AppExchange, e.g. CPQ tools, document generation, data quality products) that adds capability the core platform does not offer, without displacing what is already there.
  • Replace — building or buying something that duplicates or overrides functionality Salesforce already provides natively, whether that is a custom-built approval process next to the standard one, or an entirely bespoke object model where a standard one would do.

The point of CEER is not that any category is inherently bad. It is that these four things behave very differently over the lifetime of an org, and lumping them all together as “customisation” or worse, as a binary of “clicks vs code,” hides that difference.

Why “Replace” is the one to watch

Config and Extend broadly ride on Salesforce’s own investment. When Salesforce ships a new release, standard functionality gets faster, more secure, and more feature-rich for free. Declarative tools like Flow are actively developed, get new capabilities every release, and are documented, supported, and upgraded by Salesforce itself.

Replace inverts that relationship. Every Replace decision is a bet that your org can out-build and out-maintain Salesforce’s own platform team, indefinitely, for that specific piece of functionality. Sometimes that bet is correct — genuinely unique business logic, a regulatory requirement Salesforce cannot anticipate, a performance profile standard tooling cannot hit. Often it is not, and the org ends up carrying a parallel, custom-built version of something the platform already does, that now has to be maintained, tested, and upgraded by hand release after release, forever, with no vendor roadmap doing any of that work for you.

This is where CEER earns its keep as a measurement tool rather than just a taxonomy. Svensson’s write-up describes tagging backlog items and user stories by CEER category as work is delivered, which lets a team make statements like “25% of our solution and 70% of our delivery effort went into Replace.” That second number is the one that should get attention from architects and leadership alike — it says three-quarters of your build effort is going into the category with the worst long-term cost profile, on a quarter of the actual solution.

Why you should actually measure this

Most orgs never get to that sentence, because nobody is tracking category against effort. Salesforce’s own Well-Architected framework puts intentional design as a first principle of building “easy” solutions — and you cannot be intentional about something you cannot see. Measuring customisation level, consistently, over time, turns a vague architectural instinct (“this feels heavily customised”) into a number you can put in a steering committee deck and track release over release.

There is a real business case for doing this, and it lines up with what practitioners are already reporting about the cost of unmanaged customisation. Salesforce Ben’s coverage of technical debt notes that in recent admin surveys, technical debt has become the single biggest challenge Salesforce admins report facing — and a large share of that debt comes from customisation choices, declarative and code-based alike, made without anyone tracking their cumulative cost. A follow-up piece on reducing that debt makes the same point from the other direction: the orgs that get technical debt under control are the ones that started measuring it rather than just talking about it.

Tracking CEER category over time gives you specific, useful signals:

  • A rising Replace share is an early warning that the org is drifting away from platform-native patterns, usually gradually enough that nobody notices until an upgrade breaks something custom that a standard feature would have absorbed for free.
  • A high Config and Extend share relative to effort is a healthy sign — it means declarative, low-code, and no-code tools are doing the heavy lifting, which correlates with lower long-term maintenance cost and faster onboarding for new admins.
  • Effort concentrated disproportionately in one category, independent of solution share, tells you where your architects, code reviews, and governance process should actually be spending their attention.

None of this requires exotic tooling. A CEER label on Jira tickets or user stories, reviewed at sprint or release level, is enough to start generating a trend line. Metadata analysis tools can help retrospectively categorise an existing org, but the real value comes from tagging new work as it is delivered, so the number moves with the org rather than being a one-off audit that goes stale in a quarter.

This is not an argument against pro-code

It is worth being direct about this, because the framework is easy to misread as “code bad, clicks good.” That is not what CEER says, and it is not what this post is arguing.

Pro-code approaches exist on the Salesforce platform for good reasons. Apex and Lightning Web Components handle complexity that declarative tools genuinely cannot: intricate transactional logic, performance-sensitive bulk processing, integrations with external systems that need precise control, or business rules that would become an unreadable tangle of nested Flow elements if forced into a declarative shape. A skilled developer writing well-tested, well-documented Apex to solve a problem that actually needs it is not creating technical debt — they are making the correct engineering decision for that problem. That work would fall under Extend or, in some cases, a well-justified Replace, and CEER has no complaint with it.

The failure mode CEER is designed to surface is not “code was used.” It is customisation chosen by default — because it is the pattern the last consultant used, because it is what the developer on the bench that sprint happened to know best, or because nobody stopped to check whether Flow, a permission set, or a standard object already did the job — rather than because the problem genuinely demanded it. The same failure mode exists in the opposite direction, too: forcing something into a fragile, over-engineered Flow because “we should avoid Apex” is just as much a bad decision as reaching for Apex out of habit. CEER does not tell you which tool to pick. It tells you, after the fact and in aggregate, which tools you actually did pick, so that the pattern becomes visible and someone can ask whether it was the right call.

That is really the whole pitch: measuring customisation level is not about minimising a number for its own sake, or shaming developers for writing code. It is about giving Salesforce teams the visibility to make deliberate, defensible architecture decisions, category by category, rather than discovering the shape of their own org three years late when an upgrade breaks and nobody can explain why a standard feature was rebuilt from scratch in the first place.

Getting started

If your org has never measured this, the smallest useful first step is retrospective and rough: pick a recent release or quarter’s worth of delivered work, and sort it into the four CEER buckets by eye. You do not need precision on day one — you need a baseline. From there, add a CEER label to your backlog process going forward, review the split at each retro or release, and watch the trend rather than any single number.

The goal is not a scorecard to win. It is a shared, honest picture of where your org’s complexity actually lives, so that the decision to reach for a Flow, a permission set, an AppExchange package, or a custom Apex trigger is one your team makes on purpose — and can explain, months or years later, when someone inevitably asks why.