10,000 m
The boardroom
Why this is a governance problem
Every large Salesforce org eventually builds the same thing twice, once in Flow and once in Apex, usually by teams sitting about ten metres apart. Nobody made a bad decision. Nobody made a decision at all, which is worse.
Config versus code sounds technical, so it gets delegated to whoever happens to be building. But the consequences, the cost of change, who can maintain it, how it gets tested, land on the organisation for years. That makes it a governance question wearing a hoodie.
3,000 m
The architecture
What the standard looks like
The fix is a small, boring standard with three parts: a default, a short list of triggers that move you off the default, and a named owner for exceptions. That is the whole thing.
A standard people can recite beats a clever one nobody reads.
Boring is the point. If an engineer cannot explain the rule to a new starter in the lift, the rule is too long.
300 m
The delivery team
Rolling it out without a revolt
Start with new work only. Retrofitting the whole org is how standards go to die in committee. Put the rule in the definition of ready, make reviewers ask the question every time, and keep the exceptions in one visible place.
The exceptions list is the useful bit. When it grows in one direction, the standard is wrong, and now you can prove it.
Ground
The code
What it means in code
At ground level, the rule should be small enough to live in a pull request template. Something like this:
# Build decision, answer before you start
default: Flow
use_apex_when:
- logic needs unit tests to be trusted
- volume or limits make Flow fragile
- three or more objects change together
exceptions_owner: platform-architecture
# Not sure? Ask, then write it down.If it does not fit in a pull request template, it will not survive contact with a Friday.
