Configuration — using out-of-the-box Salesforce features (page layouts, validation rules, flows, reports). No code.
Customization — writing Apex, LWC, or other code. Or installing AppExchange managed packages.
Decision criteria, ordered by importance:
1. Out-of-the-box first. Always check if a standard feature solves the need. Salesforce ships an enormous amount of functionality; "we can configure that" is the cheapest answer.
2. Configuration second. If standard doesn't fit but declarative tools do, choose configuration. Faster to build, faster to deploy, easier to modify later, accessible to admins.
3. AppExchange third. If a packaged solution exists at reasonable cost, evaluate it. Buying often beats building when the problem is generic.
4. Custom code last. Only when configuration and AppExchange can't deliver. Code is the most expensive to build, deploy, and maintain.
Why this order matters:
- Time to market — custom code requires design, build, test, deploy, all longer than configuration.
- Future maintenance — every line of custom code is a long-term liability.
- Talent dependency — declarative config can be maintained by admins; code needs developers.
- Salesforce upgrades — out-of-the-box features evolve with the platform; custom code may need maintenance to stay current.
Common reasons code is justified:
- Performance-critical — declarative tools too slow for the volume.
- Complex bulk operations — flows can't handle.
- Custom sharing logic — only Apex Managed Sharing.
- External integrations beyond what flows support.
- Specific UX that LWC delivers.
- Very specific business logic that can't be expressed declaratively.
Common pitfalls:
- "We can build it" engineering mindset — devs prefer code; need to push back.
- Underestimating maintenance — what looks like "small custom code" becomes ongoing cost.
- Over-customising — orgs end up with thousands of custom fields and dozens of triggers, creating fragility.
A senior consultant defaults to configuration and moves to code only with documented reasons. The bias matters: every default-to-code decision adds long-term cost.