Every Salesforce engagement eventually faces the same question: should we build this with configuration, or do we need to drop into Apex and custom code? Get the answer wrong in either direction and you will pay for it in technical debt for years.
Both directions are mistakes
The custom-versus-configuration debate usually gets framed as if code is the risky choice and clicks are the safe one. That is only half right. Over-customizing is a real and well-known failure mode: you end up with Apex doing what a Flow could have done, code that only one departed contractor understood, and an org that fights every upgrade. But under-customizing is a failure mode too, and a quieter one. Teams contort themselves into fragile chains of Flows to avoid writing fifty lines of clean, testable Apex, and the result is harder to maintain than the code they were avoiding.
The goal is not to minimize code, and it is not to minimize clicks. It is to match the implementation approach to the actual complexity and lifecycle of the requirement. Salesforce gives you a spectrum, from pure declarative configuration to full custom development, and the skill is choosing the right point on that spectrum for each problem rather than applying one philosophy to everything.
The decision framework
Work through these questions in order. The first yes that fits usually tells you what to do, and writing the reasoning down is what keeps the next person from second-guessing it.
- Step 1: Can Flow or declarative tools do this cleanly? If yes, use them.
- Step 2: Will declarative work but only just barely, with awkward workarounds? Build it declaratively anyway if it is simple, but document the boundary you are pushing against.
- Step 3: Is this a one-off business process or a reusable pattern that will appear in many places?
- Step 4: How often will this change? Configuration is far cheaper to change than custom code.
- Step 5: Who will maintain this in three years, and will that person know Apex?
Notice that only two of these five questions are about technical capability. The rest are about reuse, rate of change, and ownership, because those are what actually determine long-term cost. A piece of logic that is technically buildable in Flow but will change monthly and be owned by an admin is a very different decision from logic that is complex, stable, and owned by an engineering team. Same platform, opposite answers.
When to use Apex and LWC
Reach for custom code when the situation genuinely calls for it. You are building a reusable component that will be used in many places, where the cost of building it well is amortized across all of them. The logic is genuinely complex, spanning multiple objects and steps with branching that does not fit comfortably into Flow. You need performance that declarative tools cannot deliver at your data volumes. Or you need integrations with external systems that require explicit, robust error handling.
When you do go custom, treat it like the software it is. Apex deserves test coverage, version control, and code review, the same as any production codebase. Custom that is built and maintained with engineering discipline is an asset. Custom that is dropped into the org once and never tended becomes the technical debt everyone warns you about. The code itself is rarely the problem. The lack of ownership around it is.
When to stay declarative
Stay declarative for the large category of work that is exactly what the clicks-not-code tools were built for. Single-object automation. Simple field updates. Approval processes. Most validation rules. The workflows your admins will edit regularly as the business shifts. Anything where the honest answer to "who will own this in two years" is an admin rather than a developer belongs in configuration, where that admin can actually maintain it.
The deciding factor is usually ownership and rate of change, not raw capability. If the requirement will be tweaked often by the people closest to the business, keep it in tools they can touch without a deployment. The right call is rarely about what is possible, since almost everything is possible both ways on Salesforce. It is about what will still be maintainable, by the people who will actually own it, years after the project that created it has wrapped.
Which approach fits which type of requirement?
Some requirement types lean clearly one way. Use the table as a starting point, then apply the ownership and change questions above.
| Requirement | Usual approach | Reconsider when |
|---|---|---|
| Field defaults, required fields and data checks | Validation rules and field settings | The rule needs data from many unrelated records |
| Updates on the same record or its parent | Record-triggered Flow | The same object already carries many overlapping automations |
| Guided data entry for users | Screen Flow | The screen needs custom interaction or heavy logic |
| Calculations across large numbers of records | Apex, often batch or queueable | Volumes stay small and the logic stays simple |
| Calls to an external system | Apex callouts or middleware, with error handling | A supported connector already exists |
| A custom user interface component | Lightning Web Component | A standard component or Dynamic Form covers it |
| Logic an admin must tune often | Flow reading thresholds from custom metadata | The logic itself, not just the thresholds, keeps changing |
Can you combine Flow and Apex?
Yes, and often you should. A Flow can call an invocable Apex action, so admins keep control of the process while developers own the hard step.
This split works well when one step is complex but the surrounding process changes often. Keep the Apex action small, name it clearly and give it inputs an admin can understand.
How should custom code be documented for handover?
Document custom work so a new developer can change it safely without asking its author. Store the notes with the code in version control, not in a separate file that drifts.
- The business requirement it serves, and who asked for it.
- Where it runs: the trigger, Flow, button or schedule that starts it.
- Objects and fields it reads and writes, including any it creates.
- Settings it depends on, such as custom metadata, named credentials or permission sets.
- What the test classes cover and which scenarios they leave out.
- Known limits, such as the record volume it was designed for.
- The current owner and how to reach them.
What should you ask about cost of ownership before building?
Ask who will pay for the change after the first one. The build is a single cost, but every future edit, release and handover repeats.
- Who reviews and deploys changes, and do we have that skill in-house?
- How will we test this before each of Salesforce's three yearly releases?
- Could a standard feature on the roadmap replace it later, and would we switch?
- What breaks if this component fails, and who would notice first?
- If the author left tomorrow, how long would it take someone else to change it?
Write the answers into the design notes for the feature. If nobody can answer the first two questions, lean toward configuration until someone can.
