Salesforce Flow is the platform’s primary automation engine — a visual, no-code tool that automates business processes, enforces data rules, and orchestrates complex workflows across Salesforce objects without requiring a developer. For Salesforce administrators, mastering Flow is the highest-use skill they can develop: it replaces Workflow Rules (deprecated) and Process Builder (deprecated), and it handles the vast majority of automation requirements that organisations previously addressed with custom Apex code. This guide explains what Flow does, the types of Flow available, and the most important use cases every Salesforce admin should know.
The best guide is the one that helps readers see how rules become repeatable actions.
A practical explanation should show how Flow supports everyday work rather than treating automation as a standalone feature.
That means the value is both operational and organisational.
For many teams, the biggest benefit is removing repetitive manual work while keeping the process consistent.
It should also make clear that automation works best when the business process is already understood.
A good guide should explain where Flow is most useful and why it has become such an important part of administration.
That makes it one of the most powerful tools for process automation in Salesforce.
Salesforce Flow is useful when a team wants to automate business processes without writing code. It helps move work along based on rules, conditions, and repeatable actions inside the CRM.
What Is Salesforce Flow?
Salesforce Flowis a declarative automation tool built into the Salesforce platform that allows administrators and developers to create automated processes using a visual, drag-and-drop builder —Flow Builder(accessible via Setup → Process Automation → Flows). Flow can read, create, update, and delete records; send emails; make HTTP callouts to external APIs; create Tasks and Events; post to Chatter; call Apex code; and guide users through step-by-step screen processes.
Salesforce retired Workflow Rules and Process Builder in 2023 (still accessible but no longer supported for new automations) and consolidated all automation on Flow as the single automation platform. Flow is more powerful than both deprecated tools and handles every automation scenario they covered plus many they could not. As per Salesforce’s 2026 platform documentation, Flow is the recommended and exclusively supported automation tool for all new Salesforce development.
Types of Salesforce Flow
Record-Triggered Flow
The most commonly used flow type — fires automatically when a record is created, updated, or deleted. Replaces Workflow Rules and most Process Builder automations.
Trigger options:
- When a record is created: Fires after a new record is saved — used for post-creation automation like creating follow-up tasks when a Lead is created, or sending a welcome email when a Contact is added
- When a record is created or updated: Fires whenever a record is saved — used for field updates, cross-object data synchronisation, and validation that must run on any save
- When a record is updated (if condition is met): Fires only when a specific field changes to a specific value — the most common pattern for stage-change notifications, manager alerts on large deals, and automated task creation when a deal advances to a new stage
- When a record is deleted: Fires when a record is deleted — used for clean-up automation or cascade operations that Salesforce’s native cascade delete does not cover
Timing options:
- Before save: Runs before the record is written to the database — can update fields on the same record without a DML operation. Most efficient option for field update logic
- After save: Runs after the record is committed — required for operations on related records (creating child records, updating parent records)
- Scheduled paths: An action that fires at a specified time after the trigger event — “3 days after an opportunity is created in Discovery stage, create a follow-up task”
Screen Flow
Screen Flows display guided step-by-step screens to users — collecting input, displaying information, and executing actions based on user responses. Screen Flows are launched from a button, quick action, or embedded in a Lightning page component.
Use cases: guided lead qualification scripts (presenting qualification questions in sequence with response-conditional logic), case creation wizards (walking support agents through data collection for complex cases), contract amendment processes (multi-step approval and data capture flow), and admin utilities (bulk record update tools with validation).
Scheduled Flow
Scheduled Flows run at a configured time interval — daily, weekly, or on a custom schedule — against a batch of records matching specified criteria. They are the replacement for time-dependent Workflow Rules and the tool for any recurring automation that does not depend on a record being saved.
Use cases: daily check for opportunities with close dates in the past that are still open (create manager alert tasks); weekly scan for accounts with no opportunities created in 90 days (create “check-in” tasks for account owners); monthly lead aging report generation and Chatter notification.
Autolaunched Flow
Autolaunched Flows have no user interface and are triggered programmatically — called from Apex code, Process Builder, another Flow, or via the REST API. They encapsulate reusable automation logic that multiple processes can invoke. An Autolaunched Flow that creates a standard onboarding task set, for example, can be called from a Record-Triggered Flow when an opportunity closes, from a Screen Flow when a new account is manually created, and from an API integration when a contract is signed in an external system.
Essential Flow Use Cases
1. Create a Follow-Up Task When a Lead Is Assigned
One of the highest-impact, simplest flows for any organisation. When a Lead is created and assigned to a rep (Lead Owner is populated), automatically create a Task with Subject “Call [Lead Name]”, Due Date set to today + 1 business day, and Status “Not Started”. This ensures no lead goes uncontacted and eliminates the need for reps to manually create their own follow-up tasks.
Flow type: Record-Triggered (Lead, When Created, After Save)
Entry criteria: Lead Status = New
Action: Create Record (Task) with mapped field values
2. Stage Change Notification to Manager
When an Opportunity advances to “Closed Won”, send a Chatter post to the opportunity owner’s manager notifying them of the win with the opportunity amount and account name.
Flow type: Record-Triggered (Opportunity, When Updated, After Save)
Entry criteria: Stage changes to Closed Won (ISCHANGED({!Record.StageName}) AND {!Record.StageName} = ‘Closed Won’)
Action: Post to Chatter — using a formula to address the manager and include deal details
3. Enforce Required Fields Before Stage Advancement
Before an Opportunity can advance past “Discovery” stage, require that the Next Step field is populated and the Close Date is in the future.
Flow type: Record-Triggered (Opportunity, Before Save)
Entry criteria: Stage changes to a value after Discovery in the pipeline sequence
Decision element: If Next Step is blank OR Close Date is in the past
Action (if criteria met): Add Custom Error on the Stage field — “Please populate Next Step and confirm Close Date before advancing this deal.”
4. Auto-Populate Account Fields on Related Opportunities
When an Account’s Industry or Region field is updated, automatically update all open Opportunities related to that Account with the new value — ensuring opportunity-level reporting always reflects current account attributes.
Flow type: Record-Triggered (Account, When Updated, After Save)
Entry criteria: Industry or Region is changed
Action: Get Records (related Opportunities where Stage not in Closed Won/Lost), Loop through results, Update each record with new Industry/Region value
5. Scheduled Deal Rotting Alert
Every morning at 8am, check all open Opportunities where the last Activity Date is more than 14 days ago and the Close Date is within 60 days. For each, create a Task for the Opportunity Owner: “No activity in 14 days — re-engage [Account Name] before [Close Date].”
Flow type: Scheduled Flow (runs daily at 8am)
Start criteria: Opportunities where Stage not in (Closed Won, Closed Lost) AND Last Activity Date is before Today – 14
Action: Create Task for each matching Opportunity
Flow Best Practices
- Use Before Save flows for field updates on the triggering record: Before Save flows do not consume a DML operation, making them more efficient and less likely to hit governor limits than After Save flows for the same operation
- Bulkify flows that process collections: Flows that loop through records should use collection variables and bulk DML operations (Update Records with all records in a collection) rather than one DML operation per loop iteration — the latter hits Salesforce’s 150 DML operations per transaction limit with as few as 150 records
- Use fault paths on every action: Flow elements that can fail (Create Record, Update Record, callouts) should have a fault connector that logs the error or sends an admin notification rather than failing silently
- Test in a sandbox before activating in production: Always build and test flows in a sandbox. Activate the sandbox version, test with real data scenarios including edge cases, then deploy the Flow to production via Change Set or Salesforce CLI
- Name elements descriptively: Flow element names (“Create_FollowUp_Task_On_Lead_Assignment”) make the flow readable for future administrators. Default names (“Create_Records_1”) make maintenance difficult
Conclusion
Salesforce Flow is the most powerful no-code automation tool in enterprise CRM — capable of automating processes that previously required custom Apex development, while remaining accessible to administrators without programming backgrounds. The investment in learning Flow Builder pays returns across every area of Salesforce administration: sales process enforcement, data quality automation, notification workflows, user guidance, and system integration. For Salesforce administrators looking to expand their impact, Flow proficiency is the single skill that unlocks the most value from the platform — and the Salesforce Certified Administrator exam’s 16% weighting on automation reflects how central Flow has become to the Salesforce platform’s operational model.
The best automation setup is the one that matches the actual business process. If the process itself is unclear, automation just makes confusion faster.
Common Problems and Fixes
Problem: Salesforce Flow Triggers Infinite Loops and Crashes the Org
Record-triggered Flows that update the same record that triggered them can create infinite loops, causing “Apex CPU time limit exceeded” errors that affect all users in the org. This is one of the most common Flow development mistakes. To prevent infinite loops: (1) Enable the “Recursion Prevention” option on your Record-Triggered Flow — this prevents the Flow from re-triggering on changes made by the Flow itself. (2) Add a decision element at the start of your Flow that checks whether the record fields your Flow depends on actually changed (using the {!$Record.FieldName} vs. {!$Record__Prior.FieldName} comparison) — if nothing changed, exit the Flow immediately. (3) Always test Record-Triggered Flows in a Sandbox with detailed Flow debug logging enabled (Setup > Flows > select flow > Debug) before deploying to production — loops are immediately visible in the debug trace.
Problem: Complex Salesforce Flows Are Impossible to Maintain After the Original Builder Leaves
Salesforce Flows built without documentation or naming conventions become “black boxes” that no one understands how to modify safely. Many orgs have critical business processes locked in undocumented Flows that teams are afraid to change. To build maintainable Flows: (1) Use descriptive labels for every Flow element rather than the default “Assignment 1,” “Decision 2” names — include what the element does in its label (e.g., “Check if Opportunity Amount > 10000”). (2) Add Text Template elements with documentation comments at key decision points in the Flow explaining the business logic. (3) Maintain a Flow Inventory spreadsheet tracking every active Flow, what it does, who owns it, when it was last changed, and which objects it touches — this becomes invaluable when diagnosing unexpected behavior or planning configuration changes.
Problem: Salesforce Screen Flows Don’t Appear on Mobile Devices Correctly
Screen Flows built using standard Salesforce Lightning components usually render correctly in the desktop Salesforce Lightning interface but often have layout issues when accessed through the Salesforce Mobile app. Fields may overflow, buttons may be inaccessible, and multi-column layouts collapse incorrectly. To build mobile-compatible Screen Flows: (1) Use single-column layouts for Screen Flow screens rather than multi-column section components — single-column layouts render consistently across desktop and mobile. (2) Test every Screen Flow in the Salesforce Mobile app (iOS or Android) before deploying to production — mobile rendering issues are only visible in the mobile app, not in the desktop builder. (3) Use the “Lightning Web Component” Screen Flow components from AppExchange (such as those from UnofficialSF) which are designed for mobile-first rendering and handle device-specific layouts automatically.
Frequently Asked Questions
What replaced Salesforce Process Builder and Workflow Rules?
Salesforce Flow has replaced both Process Builder and Workflow Rules as the primary automation tool. Salesforce officially announced the retirement of Workflow Rules and Process Builder — new automation should be built using Flow. Existing Workflow Rules and Process Builder automations continue to run but cannot be created anew after the retirement date. Salesforce provided migration tools (the Migrate to Flow feature in Setup) to help admins convert existing Workflow Rules and Process Builder automations to equivalent Record-Triggered Flows. If your org still has active Workflow Rules or Process Builder flows, migration to Salesforce Flow should be on your roadmap to ensure continued support and access to newer automation capabilities.
Can Salesforce Flow replace Apex triggers?
Salesforce Flow can handle the majority of use cases previously requiring Apex triggers, and Salesforce recommends using Flow instead of Apex wherever possible to reduce code complexity. Record-Triggered Flows running Before Save execute with the same performance characteristics as simple Apex Before triggers and can perform field updates, validation checks, and basic lookups without writing code. However, Flow cannot replace Apex in scenarios requiring: complex batch processing of millions of records, custom REST API endpoint development, advanced transaction control across multiple DML operations, or integration with external callout libraries. For everything else — conditional record updates, related record creation, email alerts, and approval routing — Flow is the preferred, lower-maintenance choice over custom Apex.
How do you debug a Salesforce Flow that is not working correctly?
Salesforce provides several Flow debugging tools: (1) Flow Debug Mode — available directly in the Flow Builder, it allows you to run the Flow step-by-step with test input data, showing exactly which path is taken through each decision element and what values are in each variable. (2) Flow Error Emails — Salesforce sends automated error notification emails to the Flow’s creator and org admin when a Flow fails, including the error message, the record that triggered the failure, and the stack trace. (3) Paused and Waiting Interviews — for Scheduled Flows and Flows with wait elements, check Setup > Flows > Paused and Waiting Flow Interviews for stuck or paused interview records. (4) Debug logs — for advanced troubleshooting, enable a Debug Log for the running user to capture detailed Flow execution traces alongside Apex and API activity.
Are there limits to how many Flows can run in Salesforce?
Salesforce enforces governor limits on Flow execution to protect platform performance. Key limits include: 2,000 Flow interviews can run per transaction for Record-Triggered Flows, SOQL queries within Flows count toward the per-transaction limit of 100 SOQL queries, and DML operations within Flows count toward the 150 DML statement per-transaction limit. Scheduled Flows are limited by org-level job limits. In practice, these limits rarely affect organizations running standard business automation — the limits become relevant when running Flows against millions of records in batch operations, or when multiple Flows trigger on the same record update and each performs additional queries. Salesforce’s Flow Best Practices guide recommends bulkifying Flow logic to handle multiple records per transaction rather than processing records individually.