Automation is what separates a configured ServiceNow instance from a productive one. Flow Designer is the modern automation engine for the Now Platform: low-code, visual, reusable, and equipped with hundreds of pre-built integration spokes.
Flow Designer vs Legacy Workflow
| Feature | Legacy Workflow | Flow Designer |
|---|---|---|
| UI | Drag-and-drop graph editor | Step-list interface (top to bottom) |
| Reusability | Workflows only | Flows, subflows, and actions all reusable |
| Integration | Custom scripting required | Integration Hub spokes, built-in |
| Scoping | Limited; mostly global | Fully scoped applications |
| Future of platform | Deprecated in favour of Flow Designer | The strategic direction |
New automation should always be built in Flow Designer. Legacy workflows are still supported (and still very common in mature instances) but should not be added to.
The Three Components
1. Flow
A flow is the top-level automation: it has a trigger and a series of steps that execute when the trigger fires.
Triggers:
- Record: Created, Updated, or matches a condition
- Catalog Item: Runs when a catalog item is requested (replaces legacy catalog workflow)
- Service Catalog (deprecated): Older trigger type
- Scheduled: Daily/weekly/monthly at a specified time
- Inbound Email: When an email arrives matching criteria
- REST API: Exposed as a callable endpoint
- Application: Triggered from custom application code
2. Subflow
A subflow is a flow without its own trigger — it accepts inputs, executes steps, and returns outputs. You call subflows from inside other flows. The classic use case: a "Send approval request" subflow that takes (approver, record, reason) and returns (approval result, comments) — reusable across dozens of catalog items.
3. Action
An action is the smallest reusable unit — a single step that does one thing. Examples: "Create incident", "Send email", "Update record", "Post to Slack channel".
ServiceNow ships with hundreds of pre-built actions. You can also build your own using the Action Designer, which lets you compose actions from REST steps, JavaScript steps, decision blocks, and platform operations.
Common Flow Steps
| Step type | What it does |
|---|---|
| Create Record | Insert a new record into any table |
| Update Record | Modify a record's fields |
| Look Up Record | Fetch a record by query |
| Look Up Records | Fetch a list |
| Wait for Condition | Pause until a condition is true |
| Ask for Approval | Send approval requests to one or more approvers |
| Send Email | Notification with template support |
| If / Else | Branching logic |
| For Each | Iterate over a collection |
| Try / Catch | Error handling |
The Integration Hub
The Integration Hub is the bridge between ServiceNow and external systems. It ships with pre-built spokes — collections of actions for specific platforms:
- Microsoft (Teams, Outlook, Entra ID, Intune, Azure)
- Slack
- Jira and Confluence
- Salesforce
- AWS, Azure, GCP cloud provisioning
- ServiceNow itself (cross-instance)
- SAP, Oracle, Workday
- Generic REST and SOAP for anything else
Without Integration Hub: you write a Script Include and a REST Message manually for every integration. With Integration Hub: you drag a "Post message to Slack channel" action into your flow and configure it visually.
Data Pills
Inside a flow, every step produces outputs (the trigger record, the looked-up record, the API response). These outputs are called data pills and can be dragged into subsequent step inputs. This is how you wire data through a flow without writing glue code.
Flow Designer Best Practices
- Break long flows into subflows — a flow with more than ~15 steps is hard to maintain
- Use Try/Catch for any external integration — REST calls fail; handle the failure
- Test in dev with sample data before promoting via update set
- Set flow context appropriately — by default flows run as System; sometimes you want it to run as the triggering user
- Use Action Designer for reusable units rather than copy-pasting the same step sequence into multiple flows
Sequential vs Asynchronous Execution
By default, flows execute their steps synchronously — each step waits for the previous to complete. Long-running steps (a REST call to a slow external system, waiting for an approval) automatically pause and resume the flow. The flow engine persists state in the database between executions, so a flow waiting for an approval can sit dormant for days without holding resources.
Error Handling and Retries
Each step has a configurable on-error behaviour: continue, fail flow, retry with backoff. REST integrations should always use retries — transient errors are common, and a single failure should not abort the entire automation.
Flow History and Debugging
Every flow execution is logged to sys_flow_context — the history shows which steps ran, with what inputs, producing what outputs. If a flow fails, the history pinpoints the failing step. This is the most-used Flow Designer feature in production troubleshooting.
Try It on Your PDI
- In Flow Designer, create a new flow triggered by Incident Created
- Add a "Look up Manager" step on the caller_id field
- Add a "Send Email" action that notifies the manager when a P1/P2 incident is opened for one of their reports
- Activate the flow, create a test incident, verify the email goes out
This 5-minute exercise demonstrates the loop you will repeat constantly as a ServiceNow administrator.