Recognising the anti-pattern: Flow and Apex boundaries
Why this deserves attention
Declarative and programmatic automation are complementary when their responsibilities are explicit. A sound design makes this explicit before implementation begins.
Competing automations on the same object create duplicated rules, uncertain order and difficult incident analysis. On 24 May 2025, this archive entry records the principle as a practical design concern rather than a product announcement.
Watch the warning signs
Look at flow and apex boundaries through the early signs that a convenient implementation is becoming long-term risk. The objective is not to introduce more process; it is to expose the few decisions that determine reliability, ownership and future change.
Use Flow for visible orchestration and straightforward rules, Apex for complex reusable logic, and document the boundary. Record the decision close to the solution so that delivery, support and future architecture reviews work from the same intent.
What good looks like
Administrators and developers can change the platform without surprising one another. The team can describe the expected behaviour, the owner, the evidence of success and the response when reality differs from the design.
A useful next step is to review one live implementation against this principle, identify the largest unowned assumption and turn it into a bounded improvement with a measurable outcome.
Official reference
Salesforce Apex Developer Guide