Triggers vs Flows vs Process Builder: The Migration Path Forward

The Automation Tool Timeline

Salesforce's automation tooling has evolved through three distinct generations, and understanding the history explains the current migration pressure.

Generation 1 — Workflow Rules (2004): Simple if-then automation: if a field meets a condition, do one of four actions (field update, email alert, task creation, outbound message). Simple, reliable, but severely limited in capability. Still widely used in orgs built before 2015. Salesforce has announced Workflow Rules will be retired, with creation of new Workflow Rules disabled for new orgs since 2023.

Generation 2 — Process Builder (2015): More capable than Workflow Rules — multiple criteria, multiple actions, ability to create related records and invoke Apex. But Process Builder had a fundamental architectural problem: multiple Process Builder processes on the same object fire in an undefined order, interact poorly with each other, and can create recursive loops. Process Builder is deprecated — creation disabled for new orgs, still runs in existing orgs but receives no new features. Salesforce's migration guidance is clear: migrate to Flow.

Generation 3 — Flow (2014, major investment from 2020): Flow, specifically Record-Triggered Flow, is the strategic automation tool. It consolidates Workflow Rules, Process Builder, and much of what previously required Apex triggers into a single, well-governed tool. Flow has much stronger support, active development, and Salesforce's full investment.

The Interaction Problem: Mixed Automation Stacks

The most dangerous configuration in a Salesforce org is a mix of all three automation types on the same object — a Workflow Rule, a Process Builder process, and an Apex trigger all firing on Opportunity update. The interactions are unpredictable and the combined behaviour is difficult to debug.

In the order of execution, Record-Triggered Flows fire before and after the DML operation in specific positions, Apex triggers fire before and after DML, and Workflow Rules fire after triggers in the after-update context. Process Builder also fires in the after context. When all of these are active on the same object, a change to one record can trigger a cascade of interactions where each tool's output feeds into the next tool's trigger condition.

The symptom is typically: a record update that should trigger one action ends up triggering five, or a record gets into an infinite loop of updates until the recursion guard kicks in. Debugging requires understanding the entire automation inventory for the object — which most orgs do not have documented.

-- Query to inventory all automation on a specific object
-- (useful first step before starting a migration)

SELECT Id, Name, TableEnumOrId, TriggerType,
       ProcessType, Status
FROM Flow
WHERE TriggerType = 'RecordBeforeSave'
   OR TriggerType = 'RecordAfterSave'
ORDER BY TableEnumOrId, ProcessType

-- Also check via Tooling API for WorkflowRule:
SELECT Id, Name, TableEnumOrId, Active
FROM WorkflowRule
WHERE TableEnumOrId = 'Opportunity'

Migration Strategy: Prioritisation and Approach

Most orgs cannot migrate all automation at once — the scope is too large and the risk of regression is real. A prioritised, phased approach is the only practical strategy.

Phase 1 — Inventory first: Before writing a single migration plan, produce a complete automation inventory. Every Workflow Rule, Process Builder process, Apex trigger, and Flow on every object — its purpose, its owner (the person who can validate it), and its last-modified date. Automation that was last modified 5 years ago and has an unknown owner is the highest-risk item to migrate.

Phase 2 — Retire the dead: Before migrating, deactivate and delete automation that is no longer needed. In most orgs, 20-30% of active automation is actually obsolete — processes that were built for requirements that have since changed. Migrating obsolete automation just carries the debt forward in a new tool.

Phase 3 — Migrate highest-risk first: Objects with the most automation (typically Account, Opportunity, Contact) should be migrated first because they have the most interaction risk from mixed stacks. Clear the stack on one object at a time — get it to a pure Flow (or Flow + Apex) model before moving to the next.

The Salesforce Migration Assistant

Salesforce provides a Migration Assistant tool (in Setup under Process Automation Settings) that attempts to automatically convert Process Builder processes to equivalent Record-Triggered Flows. The tool covers common patterns: field updates, record creation, email alerts.

The Migration Assistant is a starting point, not a complete solution. Its limitations are significant. It does not handle complex branching logic well. It does not validate the migrated flow's behaviour against edge cases. It cannot migrate Process Builder processes that use features with no Flow equivalent. And critically, it generates flows that are functional but not optimised — the generated flows often have redundant elements, inefficient looping patterns, and no comments explaining the business logic.

Use the Migration Assistant to generate a draft. Then review and refactor the generated flow against the original Process Builder logic and the documented business requirement. Testing the migrated automation in a sandbox with representative data volumes (not just happy-path scenarios) before deploying to production is non-negotiable.

Governance Going Forward: Preventing Flow Debt

The same automation debt that accumulated in Workflow Rules and Process Builder will accumulate in Flow if governance is not in place. The tool changed but the human behaviours that create debt — building without design, never deleting old automation, no ownership model — remain.

The governance practices that prevent Flow debt are: mandatory naming conventions (flows named by object, trigger type, and purpose), a single flow per object per trigger context where possible (rather than many small flows that interact unpredictably), a business owner assigned to every flow in the inventory, and a regular automation review (quarterly) where unused flows are deactivated and deleted.

Record-Triggered Flows should also be monitored for performance. Unlike Workflow Rules (which were lightweight), complex flows with many elements, external callouts, or inefficient loops add measurable transaction time to record saves. Salesforce's Flow Analyser in Setup can surface performance issues in deployed flows.