Subflow
A Subflow is a Flow Builder element that invokes another flow from inside the current flow.
Definition
A Subflow is a Flow Builder element that invokes another flow from inside the current flow. The called flow runs as a child in the same transaction. Input variables pass data into the called flow; output variables return data back. The parent flow waits for the subflow to finish, then continues from the element that follows.
Subflows are the modularity primitive of declarative Salesforce automation. They let teams build flow logic the way developers build code: small reusable units called from larger orchestrating flows. The result is fewer copies of the same logic, faster maintenance when the logic changes, and clearer parent flows that read like a table of contents rather than a wall of elements.
How subflows turn flows into reusable components
What a subflow actually does at runtime
When a flow hits a Subflow element, Salesforce looks up the called flow by API name, finds its current Active version, and starts a new flow interview. The interview runs synchronously inside the same transaction as the parent. Governor limits are shared with the parent: SOQL queries, DML rows, CPU time, and heap all count against the same transaction allowance. The parent waits for the subflow to reach an End element, then resumes from the next element. Output variables from the subflow are now available as resources in the parent's variable namespace under the names the parent assigned on the Subflow element.
Active version is the only version a subflow ever runs
A Subflow always calls the currently Active version of the referenced flow. There is no way to pin a parent flow to a specific subflow version. When you activate a new version of a called subflow, every parent flow that calls it picks up the change on the next interview. This is the most common cause of unexpected behaviour after a flow deploy: a parent flow seems to have broken, but the actual change was a new active version of one of its subflows. Always test parent flows against new subflow versions in a sandbox before activating in production.
Which flow types can call which
Subflows only work between compatible flow types. An Autolaunched flow can call another Autolaunched flow. A Screen flow can call another Screen flow. A Record-Triggered flow can call an Autolaunched flow. You cannot call a Screen flow from a Record-Triggered or Autolaunched flow because there is no UI context to render the screen. Flow Builder warns you if you pick an incompatible subflow at design time, and the parent flow will not save until the choice is fixed.
Input and output variables and the namespace boundary
For a flow to be callable as a subflow, each of its variables that should cross the boundary must be marked Available for input (to receive data from the parent) or Available for output (to send data back). Variables not marked stay private to the subflow. The parent and the subflow have completely separate variable namespaces. The only way data crosses the boundary is through the inputs and outputs you wire on the Subflow element in the parent. A common confusion is that the parent and subflow both happen to use a variable called recordId; they are two unrelated variables that need an explicit input assignment to actually share a value.
Governor limits and bulkification
A subflow shares the parent's transaction limits. If the parent has already used 80 SOQL queries before calling a subflow that issues 30 more, the transaction hits the 100-query limit. The same applies to DML rows, CPU time, and heap. The benefit is that a subflow operating on a record collection inherits the parent's record count, so it bulkifies naturally when the parent does. The risk is that a subflow with hidden queries inside a loop in the parent will multiply the parent's limit usage. The pattern to avoid is calling a subflow from inside a parent loop when the subflow queries records. Each iteration adds queries to the running total, and a 200-record bulk load can blow the SOQL limit in under a second.
Faults, error paths, and bubbling
When a subflow throws a fault and the Subflow element has no Fault path, the fault bubbles up to the parent. If the parent also has no Fault path on the Subflow element, the whole interview fails and the user sees a generic Salesforce error. Adding a Fault path to the Subflow element in the parent lets the parent decide what to do: log to a custom object, route to an alternate branch, send an admin email, or show a friendly screen message. Faults from inside the subflow that the subflow catches itself never bubble up; the subflow returns normally with its outputs and an error flag if you designed one.
Versioning and deploy strategy
Subflows make deploys subtler than standalone flows. Activating a new version of a subflow is effectively a deploy to every parent that calls it. The safe pattern is to test the new subflow version against every parent flow in a sandbox before activation in production. For high-risk subflows, the Flow Trigger Explorer in Setup shows which other flows depend on a given subflow, so you know your blast radius before pressing Activate. In change-set or DX deploys, subflows ship as flow components and their parents reference them by API name. Mismatched API names between source and target orgs are a common deploy break, so keep the API name stable once a subflow is referenced widely.
Build a flow as a subflow and wire it into a parent
Building a subflow means designing the called flow as a reusable component first, then wiring it into the parent. The steps below cover both halves of the work.
- Design the called flow as a component
Identify the reusable unit, like a validation, a notification pattern, or a record-prep step. Build it as a standalone Autolaunched or Screen flow. Keep its scope narrow so it stays reusable.
- Define input variables for what the subflow needs
On the called flow's Manager tab, create variables and mark them Available for input. Use clear names like recordId, sendEmail, contactList. Default values help when the parent does not assign every input.
- Define output variables for what the parent expects back
Create variables and mark them Available for output. Common outputs are isValid (boolean), errorMessage (string), createdRecordIds (collection of IDs the subflow inserted).
- Activate the called flow
A subflow only runs if it has an Active version. Activate the called flow before calling it from the parent, or the Subflow element shows an error at design time.
- Add a Subflow element in the parent flow
Drag a Subflow element into the parent. Pick the called flow by name. Assign input values from the parent's resources (variables, formulas, $Record). Pick which output variables the parent should store.
- Add a Fault path on the Subflow element
Drag the Fault path from the Subflow element to a handler: log to a custom object, set an error message, send an email alert. Without a Fault path, a faulting subflow takes the whole parent down.
Variables the subflow accepts. Must be marked Available for input on the called flow before the parent can assign them.
Variables the subflow returns. Must be marked Available for output on the called flow before the parent can capture them.
Optional path from the Subflow element that catches faults the subflow does not catch itself. Recommended on every Subflow element in production flows.
- Subflows always run the Active version of the called flow. There is no version pinning. Activating a new version of a subflow changes behaviour for every parent that calls it.
- Subflows share the parent's governor limits. A subflow with hidden SOQL inside a loop in the parent will multiply the parent's query count and hit the 100-SOQL limit fast.
- You cannot call a Screen flow from a Record-Triggered flow because there is no UI context. Use an Autolaunched subflow with output variables instead, and have the parent Screen flow render the result.
Trust & references
Cross-checked against the following references.
- Flow Element: SubflowSalesforce Help
- Considerations for Designing SubflowsSalesforce Help
- Flow Limits and ConsiderationsSalesforce Help
- Trigger Automation Decision GuideSalesforce Architects
Straight from the source - Salesforce's reference material on Subflow.
- Flow Element: SubflowSalesforce Help
- Make Reusable Pieces of Flows with SubflowsSalesforce Help
- Flow Trigger ExplorerSalesforce Help
Hands-on resources to go deeper on Subflow.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Subflow?
Q2. How do they communicate?
Q3. Why use subflows?
Discussion
Loading discussion…