When to Write Apex, When to Build Flow: An Engineering Frame for Salesforce Customization

The Salesforce platform offers two-and-a-half ways to customize behavior: declarative (Flow, Validation Rules, Approvals), Apex (custom code), and hybrid (invocable Apex from a Flow). The platform’s official guidance — “prefer declarative” — is true on average. It is also wrong often enough to cost real money when applied without thinking.

Here is the frame we use on every engagement to decide.

Question one: how often will the logic change shape?

Flow is brilliant when the shape of the logic stays stable and the inputs vary. “When an Opportunity reaches Stage = Closed Won, create a Task for the Account Owner” is shape-stable; the variables (which Opportunity, which owner) change but the logic does not.

Apex is brilliant when the logic itself is going to change every quarter because the business rules behind it change. A custom commission calculation that bumps payout tiers based on six different shifting inputs is not going to be tractable in Flow after the third revision — Flow’s debugging UX collapses under nested decision elements long before the logic does.

If the diff of your Flow over twelve months is going to be a list of “added decision branch, added variable, added action” — write Apex. Versioned text in source control is cheaper than tracing through 40 Flow elements in a UI.

Question two: who maintains it after we leave?

If the answer is “a Salesforce admin who reads English well but has not written code,” Flow is right and you should not be tempted by Apex. Even if Apex is technically the cleaner solution, the maintainer cost will eat the difference within six months.

If the answer is “an internal engineering team that already maintains a Python and Node codebase,” Apex is right. Engineers will treat Apex like they treat any other server-side language — write tests, refactor ruthlessly, version sanely. The same engineers will hate Flow because they cannot grep it.

If you do not know who will maintain it, that is the diagnosis: build nothing yet. Hire or assign first.

Question three: does this need to be auditable to a security or compliance reviewer?

Apex is reviewable. Every line is in source control, diffs are inspectable, test coverage is measurable, and a security reviewer can read it the way they read any other server-side code.

Flow is reviewable in theory and challenging in practice. The visual-graph format makes it hard to diff, hard to test in CI without custom tooling, and easy to add an “additional element” that nobody notices. For logic that touches PII, financial records, or regulated fields, this matters more than convenience.

The pragmatic rule: if a SOC 2 auditor will eventually want to see this logic, and the auditor is not a Salesforce specialist, write Apex.

The answer is almost always “both, in different places”

We rarely recommend an all-Apex or all-Flow customization. The most maintainable Salesforce orgs we have built have:

• Flow for shape-stable, admin-maintainable, low-stakes automation
• Apex for change-heavy, engineer-maintained, audit-heavy logic
• Invocable Apex called from a Flow when you need both

The shame of Salesforce customization is not that “Apex is overkill” or “Flow is for amateurs.” It is that organizations pick a side without asking which logic actually belongs on each.

What we’d do

If you are scoping a customization project and not sure where the line should fall, this is exactly the conversation we run on day one of a Forge sprint — our four-week custom build — or an MSP retainer. We bring engineering opinions, not vendor preferences. See Forge → · Book a discovery call →