Record-Triggered Flows

Why Salesforce Called Flows "The New Apex"

In 2021, Salesforce officially declared Record-Triggered Flows as the preferred automation mechanism and positioned Apex triggers as the fallback for use cases flows couldn't handle. This wasn't just product positioning — it reflected genuine architectural parity. Record-Triggered Flows can now query records, perform DML, call external services (via Apex actions), publish platform events, and execute conditional logic with the same capability that an Apex trigger provides.

The business case for the shift is clear: flows are maintained by admins, not just developers. A business analyst with Flow Builder knowledge can modify automation logic without a developer code review cycle. For organisations where development capacity is a bottleneck, declarative automation that can be maintained by a broader skill base is a genuine velocity improvement — provided the governance is in place.

Before-Save vs After-Save: The Most Important Decision

Record-Triggered Flows come in two varieties: Before-Save (runs before the record is committed to the database) and After-Save (runs after the record is committed). This is the most architecturally significant decision in Flow design, and it's frequently made incorrectly.

Before-Save Flows

Before-Save flows run before the record write. They can modify the record being saved using the $Record variable — and those modifications are included in the same database write, without using a DML statement. This makes Before-Save flows extremely efficient for field update logic: no additional DML operation, no separate record save, no Governor Limit consumption from a second DML statement.

Use Before-Save for: updating fields on the record being saved, field derivation logic (calculate a field from other fields on the same record), cross-field validation that should fire before save, and stamping values that must be set atomically with the record creation.

After-Save Flows

After-Save flows run after the record is committed. They have access to the committed record values and can perform operations that require the record to exist in the database: DML on other records, queries against the saved record, callout actions, and platform event publishing. They consume DML Governor Limits for any record changes they make.

Use After-Save for: creating or updating related records, sending notifications, publishing events, callouts to external systems, and logic that requires querying the database against the committed record.

// Before-Save Flow: field derivation (no Apex code needed)
// Equivalent to this Apex trigger — but zero DML consumed:

// Apex version (requires DML):
trigger AccountTrigger on Account (before insert, before update) {
    for (Account acc : Trigger.new) {
        // Derive SLA tier from Annual Revenue
        if (acc.AnnualRevenue >= 1000000) {
            acc.SLA_Tier__c = 'Platinum';
        } else if (acc.AnnualRevenue >= 100000) {
            acc.SLA_Tier__c = 'Gold';
        } else {
            acc.SLA_Tier__c = 'Standard';
        }
    }
}

// Before-Save Flow equivalent: Decision element with field update
// No DML statement required — modifies $Record directly
// Same Governor Limit profile as the before-trigger equivalent

Order of Execution: Where Flows Fit

Record-Triggered Flows run within Salesforce's order of execution — understanding where they fit relative to validation rules, Apex triggers, and workflow rules is essential for debugging unexpected behaviour.

The relevant order: System Validation → Before Triggers (Apex) → Before-Save Record-Triggered Flows → Custom Validation Rules → Record Saved to Database → After Triggers (Apex) → After-Save Record-Triggered Flows → Workflow Rules → Processes → Escalation Rules.

Key implications: Before-Save Flows run after Before Apex triggers. If your Apex trigger sets a field and your Before-Save Flow reads that field, the Flow sees the trigger's value. Conversely, if both the trigger and the Flow try to set the same field, the Flow runs after the trigger and overwrites it. In orgs with both Apex triggers and Before-Save Flows on the same object, field value priority must be explicitly documented.

Performance Architecture of Record-Triggered Flows

Record-Triggered Flows are bulkified by default — Salesforce processes records in batches of 200 and the Flow runtime handles all records in the batch in a single Flow execution. This is architecturally equivalent to a bulkified Apex trigger. However, several Flow element types have performance implications that differ from Apex.

Flow's Get Records element executes a SOQL query. Each Get Records element in a Flow that fires in a transaction consumes from the transaction's SOQL query limit (100 per transaction). A Flow with three Get Records elements, firing on 200 records in a batch, potentially consumes 3 SOQL queries (not 600 — Flow is bulkified). But multiple Flows on the same object can compound this.

The Loop element in After-Save Flows that performs DML inside the loop is the most common performance anti-pattern. DML inside a loop is the equivalent of the Apex "DML in a loop" anti-pattern — it fires one DML statement per iteration, consuming DML limits rapidly on large batches.

Complexity Ceiling: When Flows Become Unmaintainable

Flows have a visual representation limit beyond which they become difficult to understand. A Flow with 40+ elements spread across multiple decision branches, subflows, and fault paths is technically valid but operationally unmaintainable — a team member who didn't build it cannot debug it efficiently. This is the hidden cost of declarative automation: the visual metaphor that makes simple logic accessible makes complex logic harder to navigate than code.

The complexity ceiling manifests most severely when multiple admins have modified the same flow over time without documentation. Unlike code, Flows don't have meaningful inline comments, and the version history in Setup is coarse (version numbers without commit messages). A complex, multi-developer flow is harder to maintain than equivalent Apex code with proper comments and test coverage.

Migration: From Process Builder and Workflow Rules

Salesforce has deprecated Workflow Rules (retired in 2023) and Process Builder (scheduled for retirement in 2025). The migration path for both is Record-Triggered Flows. Salesforce provides a migration tool that converts basic Process Builder processes to Flows automatically, but complex processes with loop logic, fault handling, or scheduled actions require manual rebuilding.

The migration is not just a technical task — it's an opportunity to review and rationalise automation logic that has accumulated over years. Many Process Builder processes were built as workarounds for things that can now be done natively in Flow Builder or even in standard Salesforce configuration. Before migrating each process, evaluate whether the automation is still needed and whether the current logic is correct.

Governance for Flow-Heavy Orgs

The most urgent governance requirement for Flow-heavy orgs is an automation inventory: a documented map of every Record-Triggered Flow per object, what it does, who owns it, and when it was last reviewed. Without this, adding a new Flow to an object with five existing Flows is architectural roulette — you're working without a complete picture of what runs on that object.

Governance policies for Record-Triggered Flows: require naming conventions that encode the object, trigger type, and purpose (e.g. Account_BeforeSave_SLATierDerivation); require a description field in every Flow that explains the business purpose; require a developer code review for any After-Save Flow that performs DML or callouts; and limit the number of active flows per object with architectural sign-off required to exceed the limit.