Salesforce Flow: Types & Examples | SalesforceTutorial

Salesforce Flow Guide for Admins and Developers

Salesforce Flow is the Salesforce automation framework for record changes, guided screens, scheduled jobs, and reusable actions in Flow Builder. Use it when the process can be expressed as clear steps, tested with bulk data, and maintained by the team that owns the business rule.

This Salesforce Flow guide covers flow types, flow elements, security, limits, and Apex handoff patterns for production orgs. It also explains when using Flow is the right choice and when Apex, LWC, or an integration service is safer.

What is Salesforce Flow?

Salesforce Flow runs a sequence of configured elements. A flow can query records, evaluate conditions, assign values, call actions, show screens, and write data. Salesforce documents Flow as the tool for automating tasks and business processes, and Trailhead provides a full Flow Builder path for hands-on learning.

In enterprise orgs, design each Salesforce Flow around its transaction boundary: what starts it, what it can change, who runs it, and what should happen when one record fails. That design decision affects governor limits, sharing, debugging, and deployment.

Official references: Automate Tasks with Flows and Build Flows with Flow Builder.

How Salesforce Flow compares with Apex and older automation

For new declarative automation, Salesforce Flow is usually the starting point. Workflow Rules and Process Builder still exist in older orgs, but new work should normally be designed in Flow Builder unless a managed package, migration plan, or legacy dependency says otherwise. Use Salesforce Apex integration patterns when the requirement needs a service layer, complex transaction handling, or source-controlled code review.

What are the main Salesforce Flow types?

The flow type controls how automation starts and which elements are available. Choose it before building logic because changing the type later can require rebuild work.

Screen Flow

A screen flow runs when a user launches it from a page, action, button, utility bar, or site. Use it for guided create/update processes, service scripts, data cleanup, or approvals-related intake where the user must review information before saving.

Record-Triggered Flow

A record-triggered flow runs when a record is created, updated, or deleted. Use before-save for field changes on the triggering record. Use after-save when the automation needs a record ID, related records, notifications, actions, or work that should occur after save.

Schedule-Triggered Flow

A schedule-triggered flow runs on a schedule and processes records that match entry criteria. It fits predictable tasks such as reminder creation or stale-record updates. If record volume can exceed Flow limits, use Batch Apex.

Autolaunched and platform event-triggered flows

An autolaunched flow has no screen and can be called by another flow, Apex, or platform automation. A platform event-triggered flow starts when Salesforce receives a platform event. Use these types when the work should run behind the scenes.

Lightning Flow terminology in current orgs

Lightning flow is still a common search term, but current Salesforce setup pages and documentation generally use Salesforce Flow and Flow Builder. Use the current labels in solution designs so admins, developers, and auditors know whether you mean a screen flow, record-triggered flow, or autolaunched flow.

What are flow elements?

Flow elements are the units of work on the Flow Builder canvas. Salesforce describes an element as an action that a flow can execute, such as reading data, displaying information, evaluating logic, or changing records. Review the official Flow Elements reference before relying on a release-sensitive element.

Flow elements for data and collections

Use Get Records to query only the records and fields needed. Use Collection Filter, Collection Sort, Loop, and Transform to work with data already in memory. These flow elements reduce extra queries when a flow handles records imported through Salesforce Data Loader bulk updates.

How to build a Salesforce Flow for a record update

This example uses a common production pattern: when an Opportunity reaches a late sales stage, set a follow-up flag. Your org may use different fields, but the design steps are the same.

1. Open Setup, search for Flows, and select New Flow.
2. Select Record-Triggered Flow because the automation starts from an Opportunity save.
3. Set entry criteria so the flow runs only when the stage meets the business rule.
4. Choose before-save if you only update fields on the Opportunity. Choose after-save if you create tasks, notify users, or update related records.
5. Add a Decision element for the follow-up path and the default path.
6. Assign values, add fault paths, debug create/update/no-change cases, and activate only the tested version.

Using Flow safely in production

Using Flow safely means testing more than the happy path. Test blank values, validation rule failures, insufficient permissions, bulk imports, and integration updates. Using Flow from the UI can look correct while the same Salesforce Flow fails when 200 records are updated in one transaction.

Business process automation with Salesforce flows

Business process automation with Salesforce flows works best when the process owner can explain the rule and the Salesforce team can convert it into entry criteria, decisions, assignments, and data changes. For each Salesforce Flow, document the owner, object, trigger, active version, expected volume, rollback behavior, and monitoring plan.

Business process automation with Salesforce flows also needs a clear boundary. If the process depends on external entitlement data, complex retries, or audit-grade logging, Apex or middleware may be safer than adding callout-heavy logic directly to a flow.

How do governor limits affect Salesforce Flow?

Flows run inside Salesforce transactions and share platform limits with other automation in the same transaction. Salesforce states that when an element causes the transaction to exceed governor limits, the transaction rolls back. A Salesforce Flow that works for one record can fail during imports, API updates, or managed package automation.

• Keep Get Records, Create Records, Update Records, and Delete Records outside loops.
• Collect records first, then perform one database operation after the loop.
• Use strict entry criteria so irrelevant changes do not start the flow.
• Move heavy work to asynchronous paths, scheduled paths, Queueable Apex, or Batch Apex when save-time completion is not required.
• Monitor failed and paused interviews after deployment.

For platform details, review Flow Limits and Considerations.

How should Salesforce Flow handle security?

Security depends on the flow type, launch method, and run context. For screen flows, confirm that the user should see and edit every field displayed. For background automation, review object permissions, field-level security, sharing, and whether the automation is expected to bypass user restrictions.

When Flow calls Apex, secure the Apex class as a reusable entry point. Use sharing keywords for record access decisions, enforce CRUD/FLS with user-mode database operations or another supported pattern, and return errors that Flow can route through a fault path.

How to call Apex from Salesforce Flow

Use invocable Apex when Flow should own the process but code should own a calculation, integration call, or data operation. Salesforce exposes methods annotated with @InvocableMethod as Apex actions in Flow Builder. See the official InvocableMethod Annotation reference.

The example below is bulkified. It accepts a list of requests, performs one SOQL query, performs one DML operation, uses user-mode data access, and returns one result per request.

public with sharing class AccountRatingAction {
    public class Request {
        @InvocableVariable(required=true)
        public Id accountId;
    }

    public class Result {
        @InvocableVariable public Id accountId;
        @InvocableVariable public Boolean success;
        @InvocableVariable public String message;
    }

    @InvocableMethod(label='Rate Accounts by Revenue')
    public static List<Result> rateAccounts(List<Request> requests) {
        Set<Id> accountIds = new Set<Id>();
        for (Request request : requests) {
            if (request != null && request.accountId != null) {
                accountIds.add(request.accountId);
            }
        }

        Map<Id, Account> accountsById = new Map<Id, Account>();
        if (!accountIds.isEmpty()) {
            accountsById = new Map<Id, Account>([
                SELECT Id, AnnualRevenue, Rating
                FROM Account
                WHERE Id IN :accountIds
                WITH USER_MODE
            ]);
        }

        List<Account> updates = new List<Account>();
        for (Account accountRecord : accountsById.values()) {
            Decimal revenue = accountRecord.AnnualRevenue == null ? 0 : accountRecord.AnnualRevenue;
            accountRecord.Rating = revenue >= 1000000 ? 'Hot' : 'Warm';
            updates.add(accountRecord);
        }

        Database.SaveResult[] saveResults = Database.update(updates, false, AccessLevel.USER_MODE);

        Map<Id, Result> resultsById = new Map<Id, Result>();
        for (Integer i = 0; i < updates.size(); i++) {
            Result result = new Result();
            result.accountId = updates[i].Id;
            result.success = saveResults[i].isSuccess();
            result.message = result.success ? 'Rating updated' : saveResults[i].getErrors()[0].getMessage();
            resultsById.put(result.accountId, result);
        }

        List<Result> orderedResults = new List<Result>();
        for (Request request : requests) {
            if (request == null || request.accountId == null || !resultsById.containsKey(request.accountId)) {
                Result result = new Result();
                result.success = false;
                result.message = 'Account not found, inaccessible, or missing';
                orderedResults.add(result);
            } else {
                orderedResults.add(resultsById.get(request.accountId));
            }
        }
        return orderedResults;
    }
}

Deploy Apex with tests that prove bulk behavior and expected errors. Salesforce requires at least 75% Apex code coverage for deployment, but production teams should test behavior, not only line coverage.

What are Salesforce Flow best practices?

• Name flows by object, trigger, and purpose: For example, Opportunity – Before Save – Set Follow Up Fields.
• Keep entry criteria strict: Do not start a flow when no relevant field changed.
• Use subflows for repeated logic: Reuse routing, scoring, and validation steps instead of copying elements.
• Add fault paths: Show a useful user message or notify admins when a data or action element fails.
• Document automation order: Review Flow Trigger Explorer and release notes before each release.
• Measure outcomes: Use Salesforce reports for operational monitoring around records created or changed by Flow.

Frequently Asked Questions