Salesforce flow types: Choosing the right automation tool

Getting started with Salesforce flow types

If you've been working in the ecosystem for more than a minute, you know that picking the right Salesforce flow types is basically half the battle. I've seen plenty of projects get messy because someone used a screen flow where an auto-launched one belonged, or the other way round. Making it work is the easy part. Making sure your org doesn't crawl to a halt when you hit a certain data volume is the part people skip.

So, why does this matter? Because each flow type has its own "superpower" and its own set of limits. If you're coming from a developer background, you can think of these as different ways to hook into the execution order. If you're an admin, think of them as the different tools in your utility belt. Here's what actually matters when you're building on the clock.

Breaking down the different Salesforce flow types

Screen Flows

These are your interactive flows. If you need a user to click a button, fill out a form, or follow a guided wizard, this is what you use. I've used these for everything from simple lead intake forms to complex multi-step discount calculators. You can put them on Lightning pages, utility bars, or even launch them from a quick action. They do require a UI, though. They won't just run in the background on their own.

Record-Triggered Flows

This is the bread and butter of modern Salesforce automation. These fire automatically when a record is created, updated, or deleted, and you have to choose between "Fast Field Updates" (Before-Save) and "Actions and Related Records" (After-Save). Beginners probably overlook that choice more than any other, and it's a huge deal for performance.

• Before-Save: use these for simple field updates on the same record that triggered the flow. They're incredibly fast because they happen before the data is committed to the database.
• After-Save: use these when you need to update related records, send an email, or call an Apex action. Those tasks need the record ID, and you only get that after the save happens.

Automation flow builder with a logic diagram and the configuration panel open.

Auto-launched Flows (No Trigger)

I like to think of these as the "reusable components" of the flow world. They don't start on their own. Something else calls them: another flow, an Apex class, or even a REST API call. In my experience, if you find yourself building the same logic in three different flows, you should probably move that logic into an auto-launched flow and call it as a subflow. It makes maintenance way easier down the road.

Always use a naming convention that tells you exactly what a flow does at a glance. I usually start mine with the object name followed by the trigger type, like "Account_AfterSave_UpdateContacts".

Choosing between Salesforce flow types

So what does this actually mean in a real-world project? You'll often find yourself debating Apex vs Flow for complex logic. But even within the declarative world, the pattern you pick matters. If you're doing batch cleanup, you don't want a record-triggered flow firing 50,000 times. That's where schedule-triggered flows come in.

Schedule-Triggered Flows

These run at a specific time: daily, weekly, or just once. They're perfect for those "housekeeping" tasks. For example, I once worked on an org where we needed to deactivate users who hadn't logged in for 90 days. A schedule-triggered flow handled that every night at 2:00 AM without anyone lifting a finger. It's much simpler than writing a Schedulable Apex class.

Platform Event-Triggered Flows

These are a bit more niche but very strong for integrations. They listen for a platform event and jump into action the moment it arrives. If you're working with an external system that pushes data into Salesforce asynchronously, this is likely your best bet. It's built for that event-driven architecture.

Best practices and performance

One thing that trips people up is bulkification. Salesforce handles the heavy lifting, but you can still break things if you put a Get Records element inside a loop. Honestly, most teams get this wrong at least once. You should always look at Salesforce Flow bulkification techniques to keep your org healthy.

• Keep your logic modular. Use subflows.
• Avoid hardcoding IDs. Use variables or lookups instead.
• Test with large data sets. What works for one record might fail for 200.
• Use Before-Save flows whenever possible for speed.

When you need a little Apex

Sometimes the built-in Salesforce flow types just can't do what you need. Maybe you have a super complex calculation, or you need to call a specific legacy API. In those cases, you can use an Invocable Method to bridge the gap. Here's a quick look at what that looks like:

public with sharing class FlowAction {
    @InvocableMethod(label='Run Custom Logic' description='Do something Flow cannot do')
    public static void execute(List<Id> ids) {
        // Your custom logic goes here
    }
}

Key takeaways

• Screen Flows: use for any process that needs user input or a UI.
• Before-Save Flows: best for high-performance field updates on the same record.
• After-Save Flows: essential for related records and external actions.
• Schedule-Triggered Flows: perfect for recurring batch jobs and data cleanup.
• Auto-launched Flows: great for building reusable logic units.

Mastering Salesforce flow types comes down to knowing which tool fits the specific problem you're trying to solve. Don't overcomplicate it. Start with the simplest flow type that meets your requirements and only move to more complex patterns if you actually need the extra functionality. Whoever inherits your org will have an easier time of it.