Salesforce Flow Types Explained

Salesforce Flow is a powerful automation tool that empowers admins and developers to create custom business processes with clicks, not code​. In other words, it lets you automate tasks and guide users through workflows without writing Apex code. Flows can update records, send emails, collect user input, integrate with external systems, and much more. Salesforce provides several types of Flow, each suited for different use cases. In this article, we’ll break down the main flow types – Screen Flows, Record-Triggered Flows, Scheduled Flows, Autolaunched Flows, and Platform Event–Triggered Flows – and explain when and why to use each. We’ll also compare Screen Flow vs Record-Triggered Flow to help you understand their pros and cons.

What is a Salesforce Flow?

For those new to the concept, a Salesforce Flow (also known as Lightning Flow) is an application within Salesforce that automates business logic by flowing through a series of steps. Each flow can take inputs (like user data or record data), perform logic (decisions, calculations), and execute actions (create/update records, send emails, call Apex, etc.) in a defined sequence. Think of it as a way to create mini-applications or custom trigger logic using a drag-and-drop interface in the Flow Builder.

At a high level, all flows run in Salesforce to save time, reduce manual effort, and enforce consistency in your business processes. However, not all flows are the same. Some run with user interaction on the screen, while others run in the background automatically. Below, we’ll dive into each flow type and discuss when to use them.

Screen Flow

A Screen Flow is a type of flow that requires user interaction – it can display screens (steps) to the user and prompt for input​. Unlike other flows that run unseen in the background, Screen Flows run in the foreground as part of the user interface, meaning the user will see and interact with them on screen​. You typically use a Screen Flow to guide users through a step-by-step process or wizard. For example, you might build a Screen Flow to help a service agent create a case with guided prompts, or to walk a customer through an online form.

Screen Flows can be launched from various entry points in Salesforce. Common ways to invoke a Screen Flow include placing it on a Lightning page (e.g., as a component on a Home page or record page), launching it via a quick action or button, or even calling it from another flow or Flow Orchestration. When the flow is launched, the user will see a series of screens you designed in Flow Builder, with fields, picklists, or instructions to follow. The flow can branch based on the user’s inputs (using Decision elements) and perform actions like saving records at the end.

When and Why to use Screen Flows: Use a Screen Flow whenever you need to collect information from a user or guide them through a complex process. They are ideal for scenarios where manual input or confirmation is required as part of the business process. Some real-world examples include:

• Guided data entry: e.g. a multi-step wizard for onboarding a new account or lead, ensuring the user provides all necessary information in the correct order (maybe first entering account info, then contact info, etc.). The Screen Flow can validate inputs and reduce errors by guiding the user.​

• Self-service forms: e.g. an online form for customers to submit a support case or feedback, possibly on a community page. The flow can dynamically show or hide fields based on previous answers (using conditional visibility) to simplify the experience​.

• Internal process scripts: e.g. a call center script that sales or support reps follow while talking to a customer. The Screen Flow can present prompts and fields in sequence, so the rep knows exactly what to ask and input at each step.

In summary, Screen Flows shine when you need a user-friendly, guided experience. They improve data quality and user experience by walking users through what could otherwise be complicated tasks. The trade-off is that they require someone to initiate and complete the flow – they do not run automatically in the background.

Record-Triggered Flow

A Record-Triggered Flow is an autolaunched flow that runs automatically when a record is created, updated, or (in some cases) deleted​. In other words, this flow “listens” for changes in Salesforce records and fires without any user needing to click anything. Record-Triggered Flows operate behind the scenes (no screens or user input), making them perfect for enforcing business rules and automating system processes whenever data changes in the database​.

Record-Triggered Flows are often compared to Apex triggers or the older Process Builder rules – they are the declarative (clicks not code) way to react to DML events. For example, you can configure a Record-Triggered Flow to run every time an Opportunity is marked Closed Won, or whenever a new Contact is created. In the flow, you define what actions should happen as a result (such as updating a field, creating a related record, or sending an email). You can also set entry conditions so that the flow only runs for certain records or changes (similar to filter criteria in workflows), which helps control when the automation kicks in​.

Importantly, Salesforce lets you choose whether a Record-Triggered Flow runs before-save or after-save on the record event. A before-save flow runs prior to the record being saved to the database (like a before trigger), and is typically used to update fields on the triggering record very efficiently (no extra DML statement)​. An after-save flow runs after the record is saved (like an after trigger), and is used for actions that require the record’s ID or to perform actions on related records – for example, logging a task, sending a notification, or updating related objects​. This flexibility means you can often replace small Apex triggers with Record-Triggered Flows, achieving the same outcome with declarative logic.

When and Why to use Record-Triggered Flows: Use a Record-Triggered Flow when you need automation to happen immediately after a data change in Salesforce, without manual intervention. These flows ensure that whenever a user (or an integration) creates or updates a record that meets your criteria, Salesforce will automatically perform the specified actions. Common use cases include:

• Automating field updates: e.g. whenever an Opportunity’s Stage changes to "Closed Won", automatically update a “Closed Date” field or roll up information to a parent record (instead of requiring the user to do it).

• Assignment and routing: e.g. when a new Case is created with High priority, automatically assign it to a specific queue or notify a supervisor, ensuring urgent issues get immediate attention​.

• Related record management: e.g. if a Contact is marked “Inactive”, a record-triggered flow could automatically find all open cases for that contact and close them or reassign them. Or when a new User is created, the flow could auto-assign permission sets and send a welcome email​.

• Validation and data consistency: while validation rules handle data quality on a single record, a record-triggered flow can enforce complex business logic across objects. For instance, if an Account is updated to a certain industry, the flow can automatically create placeholder records in a related custom object for onboarding steps.

The big advantage of Record-Triggered Flows is that they run in the background, consistently, for every qualifying record change. This ensures nothing slips through the cracks (users don’t have to remember to run anything). On the downside, because they run automatically, you must carefully design them to avoid unintended consequences (like updates that trigger other automations in a loop). Always test record-triggered flows thoroughly, and use entry conditions or decision elements to prevent them from running when not needed.

Scheduled Flow

A Scheduled Flow (also known as a Schedule-Triggered Flow) is an autolaunched flow that runs at a specific time and frequency that you define – for example, every night at 2 AM or every Monday morning. Unlike record-triggered flows, scheduled flows are not tied to a particular record change. Instead, you set them up to execute as a batch job on a schedule, and they will process a batch of records meeting certain criteria. Salesforce essentially checks your conditions at the scheduled time, gathers all records that match, and then runs the flow’s logic for each record (up to a limit) in the background.

Because Scheduled Flows run in the background at a set time, they are great for routine, batch operations such as daily maintenance tasks or data syncs. For example, you could use a scheduled flow to find all accounts with an expired contract and send renewal reminder emails each week. You could also do nightly data quality updates or backups (within Salesforce), like setting a field to a default value if it was left blank during the day.

When you configure a Scheduled Flow in Flow Builder, you’ll specify the object and criteria of records to run on (similar to a report filter), and the schedule (run once on a specific date, or repeat daily/weekly). The flow will then run in bulk mode – Salesforce will create an “interview” for each record found, up to certain limits, and execute the flow actions on those records​. You can monitor and manage these scheduled flows in Setup -> Scheduled Jobs, where you can see upcoming runs or abort a scheduled flow if needed.

When and Why to use Scheduled Flows: Use a Scheduled Flow when you need to automate tasks on a regular timetable or perform bulk operations that aren’t triggered by single record changes. They are useful for maintenance and housekeeping tasks that need to happen for multiple records at once. Examples of when you’d use a scheduled flow:

• Regular data cleanup or updates: e.g. deactivate users who haven’t logged in for 90 days, running every weekend​. Or update a set of records nightly – for instance, reset a flag on all Opportunity records every day at midnight.

• Scheduled notifications or summaries: e.g. send a daily summary email to sales managers every morning with a list of opportunities closing that week. The flow could run daily, query opps meeting criteria, and send one email per manager.

• Recurring tasks: e.g. update renewal opportunities and create follow-up tasks monthly for contracts that expire in the next 30 days. The flow can run weekly to catch any that fall into the window and automate the prep work for the sales team.

• One-time bulk jobs: You can set a scheduled flow to run once on a specific date. For example, if you introduced a new field and want to backfill data on all existing records next Friday at 8 PM, you could use a one-time scheduled flow to do that instead of writing a script.

One thing to keep in mind is that Scheduled Flows currently support only daily or weekly recurrences out-of-the-box (no direct "monthly" or "yearly" option in the UI). If you have a requirement to run something annually or on a custom timetable, you'll need a workaround. (For instance, you can schedule a flow to run daily and use a formula condition to mimic a yearly run – see our blog post How to Schedule a Salesforce Flow Annually for a clever solution to this.)

Scheduled flows are great for off-peak processing. You can schedule them during non-business hours to avoid performance impact during the day​. Just be mindful of how many records your flow might process – if you need to handle extremely large volumes or complex processing, you might need Apex (Batch Apex can handle more records and flexible schedules than a flow)​. For most admin needs though, Scheduled Flows strike a nice balance by offering batch automation with clicks not code.

Autolaunched Flow (No Trigger)

An Autolaunched Flow (with no trigger) is a flow that runs in the background and does not require any user interaction to start. Unlike Screen Flows, it has no screens, and unlike the triggered flows above, it doesn’t start on its own from a record change or schedule. Instead, an autolaunched flow must be explicitly invoked by another process – for example, called from Apex code, triggered from a Process Builder (legacy), started by another flow (subflow), or via the REST API​. Essentially, it’s a set of automation steps that sits dormant until something tells it to run.

Because Autolaunched Flows have no UI, they are meant to perform background logic. In fact, Salesforce groups things like record-triggered, schedule-triggered, and platform event–triggered flows under the umbrella of “autolaunched flows” (since they run without user input)​. Here, however, we’re focusing on the generic autolaunched flow type you select as "Autolaunched Flow (No Trigger)" in the New Flow wizard. This type of flow is like a utility or subroutine – you define what it does, and then you run it from somewhere else when needed. It doesn’t run by itself until called.

Common patterns for Autolaunched Flows include using them as subflows (one flow calls another flow to perform a sub-task). For instance, you might have several record-triggered flows that all need to send a similar email. Rather than writing the email send logic in each flow separately, you could create one autolaunched flow that takes in certain input (like record Id, email template, etc.) and sends the email. Then each record-triggered flow simply calls this autolaunched flow as a subflow. This promotes reuse and easier maintenance.

Another use: you can put complex logic in an autolaunched flow and then invoke it from an Apex class or API call. If a developer or an external system needs to execute some business process in Salesforce, they could call an autolaunched flow (via the REST API or from Apex using Flow.Interview.start methods) instead of duplicating that logic in code. This way, admins can maintain the flow logic, and it can be triggered from multiple contexts.

When and Why to use Autolaunched Flows: Use an autolaunched flow when you want to create a reusable piece of automation that can be triggered by other processes or code. Key scenarios include:

• Subflow for common logic: e.g. an autolaunched flow that calculates a discount given certain inputs. Multiple other flows (screen or triggered) could invoke this subflow to get the calculation done consistently. If the logic needs to change, you update the one autolaunched flow rather than every flow that uses it.

• On-demand automation via button: e.g. you add a custom Lightning button or action on a record page that, when clicked, calls an autolaunched flow (possibly via a Lightning Web Component or a Quick Action that launches the flow). The flow then performs a series of background operations (like mass updating related records) and then perhaps navigates the user back or shows a success message. In this case, the autolaunched flow is running from a user’s click, but without any screens – it just does its job in the background and finishes.

• Invoking flows from code or external systems: If you have developers in your org, they might write an Apex trigger that, instead of containing all logic in code, invokes an autolaunched flow to do the heavy lifting. This can sometimes simplify development and allow admins to modify the flow later without altering the code. Similarly, an external integration could call into a Salesforce Flow via the REST API to, say, process an inbound message, by kicking off an autolaunched flow.

In summary, Autolaunched Flows (no trigger) are like the utility players of Salesforce automation. They run behind the scenes and give you a lot of flexibility in how they’re invoked. They won’t do anything until called, but when they are called, they can execute powerful automation steps just like any other flow (create/update records, loops, decisions, etc.). Use them to keep your automation modular and maintainable.

Platform Event-Triggered Flow

A Platform Event-Triggered Flow is a flow that fires in response to a Platform Event message being received in Salesforce. Platform Events are a mechanism in Salesforce’s enterprise messaging platform that allow apps to publish and subscribe to events (think of them as custom system notifications or messages that can come from external systems or other parts of Salesforce). When a specific platform event is published, any flow that is subscribed to that event type will automatically trigger and execute in real time​.

In essence, Platform Event-Triggered Flows let you build event-driven automation. Instead of being triggered by a record change, these flows wait for an event notification. This is incredibly useful for integrating with external systems or handling asynchronous processes. For example, imagine an external system sends a "Payment Received" event into Salesforce – you could have a platform event flow subscribe to that event and then update an Invoice record and send a receipt email, all automatically when the event arrives. Another example: an IoT device (like a smart appliance) could publish an event when it detects an issue (e.g., a printer low on toner). Salesforce receives that event and a platform event flow could handle it by creating a Case or reordering toner​.

To use a Platform Event-Triggered Flow, you first define a Platform Event (in Setup) with the fields that will be carried in the event message (similar to defining a custom object). Then, in Flow Builder, you create a new Platform Event-Triggered Flow and select that event as the trigger. From that point, you can use the event’s fields in your flow just like record data. The flow runs whenever an event message of that type is received, and it runs in the background without user interaction (like record-triggered flows, it’s autolaunched). This all happens as part of Salesforce’s Event-Driven Architecture – publishers send event messages to the Event Bus, and subscribers (like our flow) listen for those messages and react​.

When and Why to use Platform Event Flows: Use a Platform Event-Triggered Flow when you need Salesforce to respond to events from outside the normal record save process, especially for integrating Salesforce with external systems or decoupling complex processes. Scenarios include:

• External system integration: e.g. an inventory system publishes an event "Inventory Low" when stock drops below threshold. Salesforce receives this and a Platform Event Flow creates a Replenishment Order record and notifies a buyer. This is a more loosely coupled approach than directly calling an API on record save – the external system and Salesforce communicate via events.

• IoT and monitoring: e.g. a healthcare device publishes a High Blood Pressure Alert event. Salesforce’s platform event flow creates a Case for a nurse to follow up with the patient​. Or a connected machine publishes a maintenance-needed event that triggers Salesforce to log a service task.

• Cross-org or cross-app workflows: You might have multiple Salesforce orgs or apps where one publishes an event and another subscribes. Platform event flows can handle the subscriber side in a receiving org. Even within one org, you can use platform events to avoid hitting limits like Mixed DML – for instance, have a record-triggered flow publish a platform event instead of directly updating a certain object, and then a platform event flow handles that update in a separate transaction​.

• Error logging or asynchronous handling: e.g. if a Screen Flow or Apex process encounters an error, you could publish a platform event with error details, and have a platform event flow log it to a custom object for tracking. This way, the error handling is separated out and doesn’t interrupt the user’s transaction.

Platform Event-Triggered Flows are a bit more advanced, but they are extremely powerful for real-time integrations and orchestrations. They allow Salesforce to react in real time to things that happen outside of Salesforce (or in a decoupled part of Salesforce), which opens up possibilities beyond the traditional record-triggered logic.

Screen Flow vs Record-Triggered Flow (Pros & Cons)

New Salesforce professionals often ask when to use a Screen Flow versus a Record-Triggered Flow, since both can automate processes but in very different ways. Let’s compare these two flow types:

• Trigger Mechanism: A Screen Flow must be launched explicitly by a user (for example, by clicking a button or accessing a Lightning page where the flow is embedded). It runs when someone starts it and typically runs under that user’s context. In contrast, a Record-Triggered Flow runs automatically whenever a record meets the specified trigger condition (record created/updated, etc.), with no user action required​. This means record-triggered flows can fire in response to any data change (even from imports or integrations), ensuring consistent automation.

• User Interaction: Screen Flows are the only flows that present a UI to the user during execution​. They can show forms, ask questions, and guide the user step by step. Record-Triggered Flows have no user interface – the user is often unaware they even ran, except for the results (like fields updated or emails sent). Screen Flows pause for user input; Record-Triggered Flows execute start to finish in milliseconds once triggered.

• Use Case Fit: Because of the above differences, the use cases for each differ. Screen Flows are best for guided processes, data entry, and wizard-style tasks where you need to ensure users follow a procedure or provide information. They excel at things like multi-step forms, interactive wizard flows, or on-demand tasks initiated by a user. Record-Triggered Flows are ideal for background automation and enforcement of business rules – situations where, whenever data changes, you need Salesforce to automatically respond. They shine in replacing what used to be workflow rules, process builder flows, and many simple triggers: updating related records, validating data across records, sending notifications, etc., all without user intervention.

• Pros of Screen Flows: They offer a tailored user experience. You can guide users, show them contextual information, and get immediate input. This leads to better data quality and user satisfaction for complex processes (users don’t have to know what to do next – the flow tells them). Also, because a person is running it, you have the opportunity to let them review or confirm data before finalizing, which can prevent mistakes.

• Cons of Screen Flows: They are manual to start – if a user forgets or doesn’t know to run the flow, the process might not happen. They also require more design effort to make the UI intuitive, and they tie up the user’s time while the flow is in progress. You wouldn’t use a Screen Flow for something that needs to happen for every single record change (that would be impossible for users to trigger every time). In short, they’re not suitable for behind-the-scenes enforcement or high-frequency triggers.

• Pros of Record-Triggered Flows: They work behind the scenes consistently and can react to any record change, even ones from data loads or integrations. This ensures business rules are always applied. They don’t interrupt the user – Salesforce just does the work in the background. They are also highly scalable; once you set it up, it runs for every relevant record change automatically. With before-save flows, they can be extremely efficient for certain tasks (fast field updates).

• Cons of Record-Triggered Flows: Because they run automatically, you have to be careful with conditions to avoid running unnecessary logic (which could impact performance or hit governor limits). Debugging can be trickier, since they might fire in complex data scenarios. Also, they cannot interact with a user mid-process – if there's a scenario where you need user approval or input, a record-triggered flow alone can’t handle that (you’d need to combine it with another mechanism, like send an email and wait for a response, or better, use a Screen Flow or approval process for that part). In summary, they’re powerful but must be designed with care to avoid unintended side effects.

Bottom line: Screen Flows vs Record-Triggered Flows isn’t an “either/or” choice – they serve different needs. Often, a Salesforce implementation will use both: Screen Flows to guide users through optional or complex tasks, and Record-Triggered Flows to handle mandatory behind-the-scenes automation. Understanding the strengths of each will help you apply the right tool to each business requirement.

Conclusion and Next Steps

By now, you should have a solid understanding of the different types of Salesforce Flows and when to use each one. To recap: Screen Flows are for guided, interactive user experiences; Record-Triggered Flows handle automatic behind-the-scenes responses to data changes; Scheduled Flows run batch jobs on a timetable for routine tasks; Autolaunched Flows (no trigger) are reusable logic that other processes call on-demand; and Platform Event-Triggered Flows respond to real-time event messages, enabling event-driven architecture in Salesforce.

Mastering these flow types will significantly boost your power as a Salesforce Admin or Developer. With flows, you can automate complex processes, improve data quality, and build dynamic applications — all with clicks instead of writing code. As you start building, remember to plan your flows carefully, test in Sandbox, and follow best practices (for example, avoid SOQL/DML in loops, use subflows for reuse, etc.). (For a full list of tips, check out our article on Salesforce Flow Best Practices for Efficient and Scalable Automation.)

Ready to take your Salesforce Flow skills to the next level? If you want to deepen your expertise with hands-on guidance, consider enrolling in our Salesforce Flow Course. This comprehensive course walks you through building all types of flows with real-world examples and pro tips. Enroll in the Salesforce Flow course here and unlock the full potential of Salesforce automation! 🚀