Why I swear by Salesforce subflows for clean builds
Look, we’ve all been there. You open a record-triggered flow and it looks like a bowl of spaghetti with fifty different elements. This is exactly where Salesforce subflows come in to save your sanity. They let you take a chunk of logic, tuck it away in its own container, and call it whenever you need it.
I’ve seen teams build the same “Create Task” logic in five different places. That’s a maintenance nightmare waiting to happen. If you use a subflow instead, you only have one place to fix a bug or add a field. It makes your automation much easier to read and, more importantly, much easier to hand off to another admin or dev later on.
But it’s not just about keeping things tidy. It’s about building a library of tools. Think of it like this: if you have a complex calculation for sales tax or a specific way your company handles lead routing, you build it once. Then, any other flow can just “plug in” that logic without rebuilding the wheel.
When should you actually pull the trigger on a subflow?
So how do you decide if something belongs in a subflow? In my experience, there are three main signs. First, if you find yourself copying and pasting elements from one flow to another, stop. That’s a subflow. Second, if your main flow is getting so big that you have to scroll for three minutes to see the end, it’s time to break it up.
Third, if you have logic that needs to be used by both a screen flow and a record-triggered flow, you’ll need to use a subflow. Since screen flows and record-triggered flows start differently, a shared subflow is the only way to keep that logic consistent. It’s a lifesaver for keeping your data clean across different user experiences.
A step-by-step to building Salesforce subflows
1. Start with an Autolaunched Flow
Most of the time, your subflow is going to be an “Autolaunched Flow (No Trigger)”. This makes it a blank slate that waits for a parent flow to tell it what to do. Give it a clear name like “Subflow: Create Default Contact” so anyone looking at the list knows exactly what it does. If you’re just getting started with automation, you might want to review some best practices for Salesforce Flow before you get too deep into complex designs.
2. Map out your inputs and outputs
This is the part that trips people up. A subflow is like a black box. It doesn’t know anything about the record that started the parent flow unless you tell it. You need to create variables and check the “Available for input” box. If the subflow needs to send data back-like a new record ID-you have to check “Available for output”.
Pro Tip: I always name my input variables with a prefix like “input_RecordId”. It makes it crystal clear what needs to be mapped when you’re looking at the parent flow later.
3. Build and activate
Build your logic inside the subflow just like any other flow. Use your Get Records, Decisions, and Create Records elements. Once you’re done, save it and hit Activate. Here’s a catch: when a parent flow calls a subflow, it’s usually looking for the active version. If you make changes to the subflow but don’t activate the new version, your parent flow will keep running the old logic.
4. Call it from the parent flow
Now, go back to your main flow. Drop a “Subflow” element onto the canvas and search for the one you just built. This is where you map your data. You’ll see a list of those input variables you created. Pass the record IDs or collection variables from the parent flow into these slots. If you’re doing this inside a loop, be extremely careful about how you handle data to avoid hitting governor limits.
Watch out for the governor limits
One thing people forget is that Salesforce subflows run in the same transaction as the parent flow. They share the same limits for SOQL queries and DML statements. If your parent flow is already doing a lot of work and then calls a heavy subflow, you might hit a wall. If you want to stay out of trouble, check out this guide on Salesforce flow bulkification.
I always tell my colleagues to keep subflows “lean”. Don’t try to make one subflow do ten different things. Keep them focused on one specific task. If it gets too heavy, you might want to look into asynchronous paths or even Apex. Sometimes you might wonder if you should just write code instead; here’s a look at Apex vs Flow for those tough calls.
Key Takeaways
- Salesforce subflows reduce duplication by letting you reuse logic across multiple automations.
- Always mark your variables as “Available for input” or “Available for output” so the parent flow can talk to the subflow.
- Subflows share governor limits with the parent flow, so keep your logic efficient and bulk-safe.
- Remember to activate the subflow, or the parent flow won’t see your latest changes.
- Use subflows to break down “monster flows” into smaller, manageable pieces that are easier to debug.
Wrapping it up
Getting comfortable with Salesforce subflows is one of those things that separates a beginner from someone who can manage a complex org. It takes a little more planning upfront to set up the variables and mapping, but the time you save on maintenance later is huge. Start small-maybe take a common task like creating a follow-up task and turn it into your first subflow. Once you see how much cleaner your main flows look, you won’t want to go back.