Salesforce customization vs configuration
Salesforce configuration means building with point-and-click declarative tools, Flow for automation, page layouts for the interface, and validation rules for data integrity, with zero code. Salesforce customization means writing code, primarily Apex (Salesforce's backend programming language) and Lightning Web Components (its modern frontend framework), to handle logic that declarative tools can't reach. Most orgs need a mix of both, and getting the ratio wrong is one of the most common reasons Salesforce implementations become expensive to maintain.
What configuration actually covers
Configuration is anything built through Setup menus and builders rather than a code editor. Flow, Salesforce's current automation tool, handles record updates, approval processes, and multi-step logic that used to require Workflow Rules or Process Builder (both being phased out in favor of Flow). Page layouts and Lightning App Builder control what users see and where. Validation rules stop bad data from being saved, like blocking a closed-won opportunity without an amount.
The strength of configuration is that it's fast to build, easy for an admin to read and modify later, and generally safer across Salesforce's three annual platform releases, since Salesforce maintains backward compatibility for its own declarative features more aggressively than for custom code interacting with edge-case APIs.
What customization actually covers
Customization means writing Apex, an object-oriented language similar to Java that runs on Salesforce's servers, or Lightning Web Components, which use modern JavaScript and web standards to build custom interface elements. You reach for code when you need complex logic across many objects, bulk processing of large data volumes, calling external systems in ways Flow can't handle cleanly, or a user interface that Salesforce's standard components genuinely can't produce.
Custom code also has a real cost: it needs to be written by someone who understands Apex's governor limits (per-transaction resource caps that prevent runaway processes), tested with actual unit tests (Salesforce requires 75% code coverage to deploy to production), and documented well enough that the next person working on your org, whether that's an in-house admin or a Salesforce development partner, can understand what it does and why.
A practical decision framework
| Situation | Configuration or customization | Why |
|---|---|---|
| Auto-assign a lead based on region | Configuration (Flow) | Simple conditional logic, no code needed |
| Send an email when a case closes | Configuration (Flow) | Standard trigger-and-action pattern |
| Real-time sync with an external billing system | Customization (Apex) | Needs callouts, error handling, retry logic |
| Custom-branded portal experience | Customization (LWC) | Beyond what standard page layouts support |
| Complex multi-object rollup calculations at scale | Customization (Apex) | Flow can hit governor limits on large data volumes |
| Basic approval process for discounts | Configuration (Flow/Approval Process) | Built-in tool designed for exactly this |
The general rule: try to solve it declaratively first. Move to code only when configuration genuinely can't do the job, not because a developer defaults to writing code, and not because it feels more "custom" to have a bespoke solution.
Why over-customizing costs you later
The maintenance burden of a heavily customized org shows up in three ways. First, every Salesforce release (spring, summer, and winter, three times a year) needs to be tested against your custom code, since Salesforce doesn't guarantee that changes to the platform won't affect custom Apex behavior the way it does for its own declarative tools. Second, custom code is harder to hand off. A new admin can usually read a Flow and understand what it does; reading someone else's Apex class takes longer and requires actual development skills, not admin skills. Third, technical debt compounds. Custom code built without proper testing or documentation becomes a liability that slows down every future change, because nobody wants to touch it without understanding what might break.
None of this means customization is wrong. Some business requirements genuinely need code, and forcing them into declarative tools produces worse outcomes than a clean Apex class would. The goal is matching the tool to the actual requirement, not defaulting to whichever one your last developer preferred.
