Skip to main content

Salesforce Flow Builder Guide: Flow Types, Best Practices & Architecture

In plain words: Salesforce Flow is Salesforce's flagship low-code automation engine. It lets administrators and developers build guided, interactive user wizards (Screen Flows) and automated backend logic (Record-Triggered Flows) using a visual drag-and-drop builder—handling complex database updates, decisions, and external integrations without writing Apex code.

With the retirement of legacy automation tools like Workflow Rules and Process Builder, Salesforce Flow is the primary declarative automation framework on the Salesforce platform. It combines visual point-and-click usability with the power of full programming concepts—including branching decisions, loops, collection sorting, transaction rollbacks, and external REST API callouts.

1. The Core Types of Salesforce Flows

Salesforce Flow Builder provides several specialized flow types designed for distinct execution contexts:

  • Screen Flows: User-interactive wizards that present forms, collect inputs, guide users through step-by-step business workflows, and embed directly into Lightning pages, Utility Bars, or Experience Cloud sites.
  • Record-Triggered Flows: Automated backend flows that execute when a record is created, updated, or deleted. They support Fast Field Updates (Before-Save) for same-record changes and Actions & Related Records (After-Save) for cross-object updates.
  • Schedule-Triggered Flows: Batch automation routines that run on specified intervals (daily, weekly) across a specified batch of records.
  • Autolaunched Flows: Non-interactive background processes invoked by Apex, REST API, Platform Events, or subflow elements.
  • Platform Event-Triggered Flows: Event-driven automations that fire instantly upon receiving an enterprise bus platform event message.
360 Salesforce Flow Architecture Card:
  • Builder Interface: Visual canvas supporting Auto-Layout and Free-Form modes.
  • Execution Context: Runs in User Mode (respecting permissions) or System Mode (bypassing sharing/FLS).
  • Governor Limits: Bound by platform limits (max 2,000 executed elements per flow interview, SOQL query and DML limits apply).
  • Debugging & Testing: Built-in visual canvas debugger with declarative Flow Tests.

2. Flow Performance: Before-Save vs. After-Save

Choosing the correct trigger timing for Record-Triggered Flows is vital for system performance and governor limit optimization:

  • Fast Field Updates (Before-Save): Runs before the record is saved to the database (10x faster). Used whenever you only need to update fields on the record that triggered the flow. It requires no DML update element, directly manipulating $Record.
  • Actions & Related Records (After-Save): Runs after the record is committed to the database. Required when updating child/parent records, sending email alerts, making external callouts, or publishing platform events.
Step-by-Step Example: Automatic Account Tiering & Task Assignment
When an Opportunity moves to Stage = 'Closed Won' with an amount exceeding $50,000:
  1. Start Condition: Record-Triggered Flow on Opportunity (Optimize for: Actions & Related Records). Filter: IsWon Equals True and Amount Greater Than 50000.
  2. Update Parent Account: Use an Update Records element to set the parent Account's Rating to 'Hot' and Customer_Tier__c to 'Platinum'.
  3. Create Welcome Task: Use a Create Records element to assign an onboarding task to the Account Owner.
  4. Fault Handling: Connect a Fault Path from the Create Records element to send an automated notification to administrators if the task creation fails.

3. Advanced Logic, Loops & Bulkification

Because flows execute within Salesforce governor limits, bulkification is critical when processing multiple records:

  • Collection Variables: Store lists of records in collection variables (Record Collection Variable) rather than operating on records one at a time.
  • Transform & Collection Filters: Use native Transform and Collection Filter elements to map data and filter lists in memory without executing additional SOQL queries.
  • Subflows: Modularize reusable business logic into separate Autolaunched Flows, calling them from parent flows to eliminate duplicate configurations.

4. Common Traps & Architect Best Practices

Developer Trap: Putting DML Operations or SOQL Queries Inside Loops
Placing a Get Records, Create Records, or Update Records element inside a Loop will cause the transaction to hit governor limits (100 SOQL queries / 150 DML statements) when processing bulk data. Always build a collection inside the loop using an Assignment element and execute a single DML operation outside the loop.
Core Rule: Use Fast Field Updates (Before-Save) for same-record updates, keep all DML and SOQL elements strictly outside loops, and always configure Fault Paths on database operations.
  • Set Trigger Order: Use the Trigger Order field (values 1–2000) on Record-Triggered Flows to explicitly control the execution sequence of multiple flows on the same object.
  • Add Fault Connectors: Every database element (Create, Update, Delete, Get) should have a red Fault Path leading to an error handling screen or custom logging subflow.
  • Use Flow Test Framework: Create declarative unit tests inside Flow Builder to verify happy paths and failure scenarios before activating flows in production.

Summary

Salesforce Flow Builder is the engine of modern declarative development. By mastering flow types, optimizing between Before-Save and After-Save execution paths, maintaining strict loop bulkification, and implementing robust fault handling, administrators and developers can build scalable, high-performance business automations with confidence.