Master Salesforce Flow Types: Decision Matrix, Governor Limits, and Best Practices

⚡ 1-Minute Summary

• Follow the hierarchy: Start with simple configuration, then move to Flow, and only use Apex when strictly necessary.
• Choose the right trigger context: Use before-save to update fields on the record being saved. Use after-save when updating related records, sending notifications, or running async paths.
• Protect your governor limits: Never place queries or DML statements inside loops. Collect records into collections and execute a single DML operation outside the loop.

Module Map: The Complete 360° Automation Architecture

MODULE ROOT: 'Which automation tool should you use, and will it survive bulk processing?'
├── Flow Types: 5 core flavors for 5 distinct execution contexts
├── Flow vs. Apex Decision Matrix: Complexity and governor limits threshold
├── Bulkification & Recursion Guards: Preventing the #1 Flow failure mode
├── Before-Save vs. After-Save Cost: Zero extra DML vs. an additional save cycle
├── Fault Paths, Subflows, & Invocable Handoffs: Resilient enterprise design
├── Approval Processes: Record locking and placement in the Order of Execution
└── Queues & Assignment Rules: Routing records to the right teams
    └── Cross-Links: Order of Execution, Trigger Frameworks, and Asynchronous Apex

Understanding Salesforce Flow Types

💬 In plain words: Salesforce Flow comes in five main types. Select the right type based on what starts the automation: a human interaction (Screen Flow), a database save event (Record-Triggered Flow), an automated schedule (Schedule-Triggered Flow), an external process (Autolaunched Flow), or a decoupled message (Platform Event-Triggered Flow).

📌 Practical Scenarios:

• Return merchandise wizard: A support rep walks through interactive, dynamic questions → Screen Flow.
• Same-record field updates: Auto-populating the Region field on a new Case from its parent Account → Before-Save Record-Triggered Flow.
• Nightly cleanup job: Flagging stale Opportunities across thousands of records → Schedule-Triggered Flow.

🧠 The Five Core Types: Screen flows guide users, record-triggered flows react to saves, scheduled flows run on a timer, autolaunched flows act as reusable utilities, and platform event flows listen for messages.

Core Architectural Concepts

Salesforce Flow is the standard declarative engine on the platform. Each type runs within a specific system context and handles execution limits differently:

• Screen Flows: Interactive, user-facing wizards launched from Lightning record pages, utility bars, Quick Actions, or Experience Cloud sites. They run in user context by default, and support reactive screen components that update in real time without clicking "Next".
• Record-Triggered Flows: Execute automatically in system context during a database transaction. They operate in three modes: Before-Save (ultra-fast field updates without extra DML), After-Save (related record updates, external callouts, and asynchronous paths), and Before-Delete.
• Schedule-Triggered Flows: Run in batches at designated dates and times over a filtered set of records. Each record runs in its own interview.
• Autolaunched Flows: Reusable headless services without triggers or UI. They are called directly from Apex, REST APIs, custom buttons, or parent subflows.
• Platform Event-Triggered Flows: Event subscribers that run asynchronously in automated system context when a platform event notification is published.

🧭 360 Card: Salesforce Flow Types

• Core Rule: Select the Flow type strictly by what triggers it: an interactive user, a database commit, a scheduled clock, an external caller, or an event message.
• Key Gain: The declarative engine manages execution contexts automatically across a wide range of business needs.
• Best Practices: Choose Before-Save for same-record field updates. Use After-Save when updating other records. Use Autolaunched for reusable subflows. Reserve Screen Flows for human interactions, and Schedule-Triggered Flows for recurring batch jobs under daily volume thresholds.
• Trade-Offs: Each Flow type follows distinct execution rules and context limitations. Choosing the wrong type can cause performance issues at scale.
• Governor Limits: Before-Save cannot perform DML on related records. Schedule-triggered queries handle batches of up to 200 records per batch, up to a total of 50,000 records. Standard org limits allow up to 250,000 schedule-triggered flow interviews per 24-hour period (or 200 × user licenses, whichever is greater).
• High Volume Architecture: For millions of records, use Batch Apex or Data Cloud pipelines instead of schedule-triggered flows.

Technical Deep Dive: Questions & Architectural Scenarios

Q: How do you choose the right Flow type based on use case and governor limits?

🎯 Core Rule: Use before-save for same-record updates; use after-save for related records and asynchronous operations. Use scheduled for recurring jobs, screen for user workflows, autolaunched for subflows, and event-triggered for event listeners.

Answer Breakdown:

• Before-Save Record-Triggered Flow: Runs before the record is committed to the database. It updates fields on the triggering record without executing an extra DML statement or restarting the save cycle.
• After-Save Record-Triggered Flow: Runs after the record is saved to the database. Required when creating or updating related records, sending notifications, executing asynchronous actions, or making callouts.
• Schedule-Triggered Flow: Best for recurring, scheduled batch updates. Because each record executes as its own interview, total record volume must fit within daily scheduled Flow limits.
• Screen Flow: Provides interactive user interfaces, screen navigation, and real-time reactive field updates.
• Autolaunched Flow: Contains reusable logic that can be invoked on demand by Apex triggers, custom controllers, or external REST endpoints.
• Governor Limit Impact: All Flow operations share standard transaction governor limits (such as SOQL queries and CPU time) with triggers and workflows in the same execution context.

Scenario 1: A schedule-triggered flow processing 3 million records fails. What went wrong, and how should it be redesigned?

Solution:

⚠️ Scalability Trap: Schedule-triggered flows are not built for enterprise-scale data volumes of millions of records. High volumes quickly hit daily interview limits and total execution timeouts.

• Root Cause: Schedule-triggered flows create one interview per record and enforce daily interview caps. Processing 3 million records exceeds declarative scheduling limits.
• Architectural Fix: Migrate the workload to Batch Apex using a Database.QueryLocator, which supports up to 50 million records. Batch Apex provides configurable chunk sizes (1 to 2,000), error handling via Database.RaisesPlatformEvents, state management, and detailed execution monitoring.
• Rule of Thumb: When processing recurring datasets larger than 100,000 records daily, use Batch Apex instead of scheduled declarative flows.

Scenario 2: How do you build a single business logic process that works for both a Screen Flow UI and an external REST integration?

Solution:

• Decouple UI and Logic: Place core business logic in an Autolaunched Subflow or an @InvocableMethod Apex class.
• Build Thin Entry Points:
  • Create a Screen Flow that collects user inputs and passes them into the autolaunched subflow.
  • Expose the autolaunched subflow directly to external integrations through standard Salesforce REST endpoints (/services/data/vXX.X/actions/custom/flow/...).
• Architectural Benefit: Centralizes business logic in a single reusable component, preventing duplicate logic across UI and API channels.

Comparison: Record-Triggered Flow vs. Autolaunched Flow called from an Apex Trigger

• Record-Triggered Flow: Initiated directly by the Salesforce platform during the record save process. Its timing is governed by the standard Order of Execution.
• Autolaunched Flow (Invoked from Apex): Called explicitly from an Apex trigger handler using Flow.Interview.createInterview(). This gives developers precise control over execution sequence, entry criteria, and bulk collections.
• Summary: Use Record-Triggered Flows for declarative automation on record saves. Use Autolaunched Flows when logic needs to be reused across Apex, REST APIs, or multiple processes.

Expanding to Flow Orchestration

Standard flows are designed to run within a single transaction. Flow Orchestrator coordinates complex, multi-user business processes that span multiple people, departments, and days:

• Stages and Steps: Organizes business processes into sequential or parallel stages containing interactive and background steps.
• Interactive Steps: Assign tasks and Screen Flows to specific users, Public Groups, or Queues, pausing execution until the user completes the step.
• Background Steps: Execute autolaunched flows, call external APIs, or run Apex actions automatically without user intervention.
• Key Use Cases: Employee onboarding, multi-tier deal approvals, cross-department handoffs, and complex claims processing.
• Notifications: Integrate with Custom Notifications to send alerts to desktop and mobile devices when work items are assigned.