If you already know the basics about Salesforce Flow, you’ll know what it is and why it’s such a powerful automation tool. It’s time to talk about the different types of Flows, because, yes, there’s more than one, and knowing when to use each type is one of the most important things to learn early on.
The key here is not to memorize every detail, but to understand the categories and get familiar with the pain points they’re designed to solve. Here’s a quick rundown of the five main Flow types.
1. Screen Flow
This is my personal favorite, mainly because it does something neither Process Builder (PB) nor Workflow Rules (WF) could ever do. It’s the only Flow type that actually shows up on the screen and interacts directly with users.
You know how, sometimes, you want to guide someone through a process, step by step, without overwhelming them with a bunch of fields or instructions on a page? That’s where Screen Flows take the stage (or screen, pun intended). Think of them like guided forms or mini-wizards that collect input, show or hide fields based on answers, and help users complete a process with confidence.
“Well, why can’t we just rely on the record’s visible fields, field-level security, record types, and validation rules to handle visibility or data quality?”, you might ask. “Don’t those already make sure the right things get filled out?”
Fair question – but here’s the thing: relying solely on the record page can leave too much room for error. Users might skip important fields, enter incorrect values or formats, or miss critical context. Sure, required fields and validation rules help, but they’re blunt tools. They kick in after the user tries to save, displaying an error and forcing them to go back and correct the issue. Wouldn’t it be better if users just got it right the first time?
Screen Flows make that possible by guiding users through the entire process from the very beginning. Instead of correcting mistakes after the fact, you’re preventing them from happening at all.
Some examples of when to use Screen Flows are:
- Onboarding new customers
- Logging support cases
- Guiding internal teams through complex processes
- Creating a guided product return or exchange request
- Creating an internal reimbursement request form (check out this guide on how to let users upload multiple files in Screen Flows…perfect for attaching receipts!)
And if you’re looking to take your flows up a notch, consider using progress indicators to make long forms more user-friendly or explore these handy components that can make your screen flows look better and work smarter – no custom development required.
So you see, screen flows are interactive and customizable, ultimately enhancing the user experience. Once you build your first one, it’s easy to see why this Flow type opens up so many possibilities.
2. Record-Triggered Flow
If Screen Flows are all about user interaction, Record-Triggered Flows are all about *behind-the-scenes* automation. These Flows don’t wait for someone to click a button, as they can fire automatically when a record is created, updated, or deleted.
Record-Triggered Flows are considered your silent workers, as they keep your org running in the background, handling routine actions. You set the conditions, tell the Flow what to do, and the next time there’s a record that matches those conditions, automation happens instantly.
If you’re a seasoned admin who’s been using PB and WF in the past, this is where most of that logic now belongs. If you’re updating a related record, sending a notification, or setting a field value based on conditions, Record-Triggered Flows can do all of that and more.
But why switch, really? Because PB and WF are on their way out! No really, and even if they weren’t, Record-Triggered Flows give you way more flexibility.
You can build logic that runs before or after the record is saved (yep, kind of like Apex triggers), perform cross-object updates, loop through related records, and even call subflows. You’re no longer restricted to just a handful of basic actions (like in Workflow Rules) or a mile-long chain of criteria nodes (like in Process Builder).
If you’re unsure whether your use case calls for a before-save or after-save Flow, this guide can help you figure it out.
Here are some specific examples of when to use Record-Triggered Flows:
- Automatically create a Task when a high-priority case is created.
- Update the Opportunity Stage when a related Quote is marked as Approved.
- Recalculate a custom field whenever a related child record changes.
- Assign a custom object to the appropriate queue depending on a field’s value.
Once you start building these, it’s hard to go back. It feels like magic: a record changes, and everything else responds instantly with no extra clicks. So, if your goal is to build powerful, set-it-and-forget-it (wait no, don’t actually forget it, but do make clear names and descriptions) automations, Record-Triggered Flows are your new best friend.
They’re fast, reliable, and obviously a huge step up from the automations of the past. And if you’re wondering what pitfalls to avoid as you start, this article gives an overview of the kind of things you’ll wish you’d known sooner.
3. Scheduled-Triggered Flow
If Record-Triggered Flows are your silent workers, then Schedule-Triggered Flows can be considered your planners: quietly taking care of routine tasks like clockwork. The trigger isn’t a change in data like in the previous one, but simply the passage of time.
These Flows are perfect when you want something to happen on a schedule, like every night, for example, or maybe at midnight or on the first day of each month. Due to their time-driven nature, they’re perfect for sending reminders, updating stale records, or even checking for missing data. Whatever it is, just set the criteria and timing, map out what it’s supposed to do, then Salesforce handles the rest.
As for use cases? There are plenty. Check these out for specific examples:
- Every Monday, check for open Opportunities with no upcoming tasks and send reminders to owners.
- On the first of each month, update “Customer_Since__c” dates for Accounts created in the last 30 days.
- Every night, find inactive Cases and update their status to “Archived”.
- Every Saturday, deactivate active sales team members who have not logged into Salesforce in over 60 days.
One of the best parts about Schedule-Triggered Flows is that they can run for a batch of records that satisfy your criteria, processing that group of records all at once, which is a huge win for efficiency.
So if you have a task that’s routine, time-based, and doesn’t need a user to kick it off, Schedule-Triggered Flows are exactly what you’re looking for. Set it, let it run, and check in now and then under Setup > Scheduled Jobs to make sure everything’s still running smoothly.
4. Autolaunched Flow
Okay, confession time: when I first heard the term Autolaunched Flow, I thought they just… ran on their own. No trigger, no button, just magically launched somehow. I mean, auto-launched, right? But as I eventually realized (and maybe you have too), it’s not quite that simple.
In Flow-speak, “autolaunched” (with a lowercase a) is an umbrella term for any flow that runs without screens or user interaction. That includes: Record-Triggered Flows and Schedule-Triggered Flows, which we both discussed earlier.
The Autolaunched Flow (No Trigger) and with an uppercase A starts because something else calls it (like another Flow, Apex, or a button for example). The “No Trigger” part just means the flow doesn’t decide on its own when to start; rather, it’s waiting for an outside nudge.
Here are some examples of when you might use an Autolaunched Flow:
- A button on a record page launches a Flow that performs backend tasks (like mass updates for example)
- An Apex trigger invokes a Flow to automate part of a custom process
- Another Flow hands off part of its logic to a separate Autolaunched Flow
- A Process identifies a condition and calls a Flow to update related records
The third example is great for breaking complex logic into reusable chunks. Instead of repeating the same steps across multiple Flows or automations, you can create one Autolaunched Flow and call it wherever it’s needed. One example is in this situation, where a reusable Flow handles fault paths so you don’t have to rebuild them manually each time. They’re quiet, efficient, and ready when you are.
5. Platform Event-Triggered Flow
Ah, another type of autolaunched flow! You can think of this type as a listener on standby, waiting for a signal to act. The go-signal is a Platform Event that, when published, is picked up by the flow and responds instantly. If you’re unsure of what platform events are and how they work, make sure to check this article out.
Usually, this type of flow is for the more advanced users, as they listen to platform events, which are a way for different parts of the system to talk to each other asynchronously. So, unless you’re dealing with integrations or complex business processes, you might not touch this Flow type for a while. It’s good to know, though, that it’s usually built to respond to events as they happen, so that makes it ideal for near-real-time updates and integrations.
Use it when:
- You’re working with integrations or system-to-system communication.
- You want to respond to something that happens outside the regular record lifecycle.
Flow Types at a Glance
We’ve walked through each type one by one, so here’s your side-by-side cheat sheet for when you just need the facts, and a final column to help you remember their “vibe” at a glance.
You can explore a comprehensive overview of even more Flow types if you’d like to dive deeper beyond the main five.
Bonus: A Quick Look at Orchestrations
Think of an orchestration like a conductor leading an orchestra. The orchestra brings together different people and instruments, and the conductor leads them to create a harmonious performance. In Salesforce, orchestrations coordinate complex business processes by managing multiple flows and human tasks in a well-structured sequence.
Yes, it’s kind of like simply calling one flow from another, but the nice thing about orchestrations is that they offer enhanced visibility, plus the capability to add steps and stages, making them perfect for use cases that involve multiple users or departments.
Steps are the building blocks of an orchestration. A background step can call for an existing active Autolaunched flow, and an interactive step can call a screen flow. These steps can assign a user to that flow. You can dictate more in a step, like what record page the flow should appear on, or whether the user should get an email notification.
Stages are groups of steps. The steps in a stage are executed in the sequence they are in, or in parallel, depending on your business need. These stages can be separated by decision elements to allow for more complex logic.
Simply put, if you need to combine automation and collaboration across teams, orchestration is the key.
Final Thoughts
You don’t have to memorize anything, but I hope this guide gives you a better idea of how to recognize what’s possible with different types of flow.
Nailing the right Flow type helps you automate smarter, not harder. And if you’re ever unsure what type of Flow to create, just head to Setup → Flows → New Flow, and Salesforce actually has a nice visual picker to guide you.
