Subflows let you build reusable pieces of automation that any flow can call. This guide shows you how to create one, define its inputs and outputs, and call it from parent flows.
Why you build subflows
Before subflows, repeating the same logic across multiple flows meant copying and pasting the same steps everywhere. When that logic needed to change — updating an API endpoint, fixing a bug, adding error handling — you had to hunt down every flow that used it and update them individually. Platform teams maintaining dozens of flows would spend hours on changes that should take minutes. Worse, you'd inevitably miss one, creating inconsistent behavior across your automation.
How subflows work
A subflow is a flow that other flows call like a function. You define inputs (the data flowing in) and outputs (the data flowing out), then build the logic in between. Parent flows call subflows using the 'Subflow' action, pass in the required inputs, and get the outputs back. Subflows run synchronously — the parent flow waits for the subflow to complete before continuing. Think of them as reusable functions: you write the logic once, define a clean interface, and call it anywhere you need that functionality.
Making subflows production-ready
A basic subflow works, but production subflows need proper error handling and clear documentation. Add error outputs so parent flows can handle failures gracefully. Use descriptive names for inputs and outputs — not 'input1' but 'user_sys_id' or 'approval_decision'. Consider versioning: when you need to make breaking changes, clone the subflow and update parent flows gradually. Most importantly, test changes in sub-production first — a broken subflow breaks every parent flow that calls it.
Before you start
- •flow_designer role or admin role
- •Understanding of Flow Designer basics and flow variables
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Create the subflow
Navigate to Process Automation > Flow Designer. Click New > Subflow. Give it a descriptive name like 'Create Incident and Send Notification' — avoid generic names like 'Helper Flow'. Set the Application scope to match where you'll use it most. The description matters here because other developers will see it when browsing available subflows.
Define input variables
Click the Inputs tab, then New. Create an input for each piece of data the parent flow will pass in. Set the Type based on what you're receiving — String for text, Reference for sys_ids, Boolean for true/false values. Check 'Mandatory' for inputs the subflow can't work without. Use clear names like 'caller_user_id' or 'priority_level' — these names appear in the parent flow's Subflow action.
Build the subflow logic
Add steps just like any flow — drag actions from the palette onto the canvas. Reference input variables using the data picker or pills. The key difference: keep the logic focused on one reusable task. If you're creating an incident and sending a notification, do both here. But don't add unrelated steps that only some parent flows need.
Define output variables
Click the Outputs tab, then New. Create outputs for data the parent flow needs back — typically the sys_id of records you created, success/failure status, or calculated values. Set appropriate types and descriptive names. Map each output to a flow variable or step output from your subflow logic. Always include an error output so parent flows can detect when something went wrong.
Test the subflow
Click Test from the subflow designer. Provide sample values for all mandatory inputs. Run the test and verify the outputs contain expected data. Fix any errors before publishing — debugging is easier in the subflow than tracking down issues in parent flows later.
Use realistic test data, not 'test123' — some actions behave differently with real record references.
Publish and activate
Click Publish to make the subflow available to parent flows. Then Activate it so it actually runs when called. The subflow appears in the Flow Designer action palette under 'Subflow' for other flows in the same application scope.
Call from parent flow
In your parent flow, drag 'Subflow' from the action palette. Select your subflow from the dropdown. Map parent flow variables to the subflow inputs using the data picker. After the Subflow action, you can reference its outputs in subsequent steps. The parent flow waits for the subflow to complete before continuing to the next step.
Best practices
Test subflow changes in sub-production first — a single broken subflow can break dozens of parent flows that call it.
Always define error outputs and handle them in parent flows rather than letting subflows fail silently.
Keep subflows focused on one reusable task — don't build kitchen-sink subflows that try to handle every variation.
Use descriptive names for inputs and outputs because other developers see these when building parent flows.
Document what the subflow does in the description field — 'Creates incident with proper assignment and sends email notification' beats 'Incident helper'.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue