Flows give you a visual way to automate ServiceNow processes without writing code — they're what ServiceNow built to replace Workflows for all new automation. This guide walks you through creating your first Flow from trigger to published automation.
Why ServiceNow built Flow Designer
Before Flow Designer, every process automation lived in the legacy Workflow editor — a clunky interface that made simple automations needlessly complex and debugging a nightmare. Workflows also mixed server-side and client-side logic unpredictably, leading to performance issues and hard-to-trace execution paths. ServiceNow stopped enhancing Workflows years ago and built Flow Designer as the modern replacement. The people building automations — platform developers and power-user admins — now have a clean visual interface that runs predictably server-side and integrates with the broader ServiceNow platform through a standardized action catalog.
How Flows work and what you're building
A Flow is a server-side automation that starts with a trigger (when something happens), executes a sequence of actions (what to do about it), and runs to completion without user interaction. You'll pick from three trigger types: record-based (when a record changes), schedule-based (time-driven), or application-based (started by other platform features). Actions come from a centralized catalog — some are built-in ServiceNow actions like creating records or sending emails, others are custom actions your team builds. The visual designer shows the execution path clearly, and published Flows run automatically when their trigger conditions are met.
From working Flow to production-ready automation
Most first Flows are linear — trigger fires, do a few actions, done. The enhancements that make Flows production-quality are: adding conditional logic to handle different scenarios, using data pills to pass information between actions cleanly, and building error handling so failed executions don't disappear silently. You'll also want to understand the difference between Flows (complete automations), Subflows (reusable chunks of logic), and Actions (individual steps you can share across multiple Flows). Advanced Flows use lookups to query data, loops to process multiple records, and custom actions to encapsulate complex logic your team reuses.
Before you start
- •action_designer role or admin role
- •Process Automation plugin activated (should be active by default)
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 Flow record
Navigate to Process Automation > Flow Designer and click New > Flow. Give it a descriptive name that explains what process it automates — avoid generic names like 'Incident Flow.' Set the Application scope to your custom application if you're building for a specific business process, or leave it as Global for platform-wide automation.
Use naming conventions like 'Auto-assign P1 incidents' or 'Send manager approval for high-value requests' — you'll thank yourself when managing dozens of Flows later.
Configure the trigger
Click 'Add a trigger' and choose your trigger type. For record-based triggers, select the table and specify when it fires (created, updated, created or updated). Set conditions to narrow when the trigger fires — don't run on every record change. For schedule-based triggers, set the frequency and time window. Application-based triggers connect to Service Catalog, Virtual Agent, or other ServiceNow features.
Record-based triggers on high-volume tables like Task can kill performance — always add meaningful conditions to limit execution.
Add your first action
Click the plus icon after your trigger and select 'Add an Action.' Browse the action catalog or search for what you need — common starting points are 'Create Record,' 'Update Record,' 'Send Email,' or 'Ask for Approval.' Each action has required inputs (marked with red asterisks) and optional ones. Use the data pill picker to connect trigger data to action inputs.
Data pills are your connection between steps — the trigger record's fields become available as data pills to use in subsequent actions.
Build the action sequence
Continue adding actions by clicking the plus icons in your Flow. Actions execute in order from top to bottom. Use 'Add a Condition' to create branching logic when you need different actions for different scenarios. Each condition creates separate execution paths — add actions to the 'Then' and 'Else' branches as needed.
Keep your first Flow linear until you understand how data pills flow between actions — complex branching can wait for Flow #2.
Test the Flow logic
Click 'Test' in the top right to run your Flow against test data. For record-based triggers, you'll specify which record to use as the trigger. For schedule-based triggers, the test runs immediately. Watch the execution in the test panel — each action shows green (success), red (error), or gray (skipped). Click individual actions to see their inputs and outputs.
Test with edge cases, not just happy path data — missing field values and unexpected record states reveal logic gaps early.
Publish the Flow
Once testing passes, click 'Publish' to activate your Flow. Published Flows run automatically when their trigger conditions are met. You'll see a confirmation that shows the Flow version number — ServiceNow keeps previous versions so you can roll back if needed. The Flow status changes from 'Draft' to 'Published' and it becomes available for the platform to execute.
Always test thoroughly before publishing — while you can roll back, any automation that already ran on live data can't be easily undone.
Best practices
Always add meaningful conditions to record-based triggers — Flows that run on every record update will slow your instance to a crawl.
Use descriptive names for Flows and their actions so the execution log makes sense six months from now when something breaks.
Keep Flows focused on one business process — a Flow that tries to handle multiple unrelated scenarios becomes unmaintainable quickly.
Test Flows with real data that includes edge cases like missing values and unexpected field states before publishing.
Set up proper error handling using 'Add Error Handler' for actions that might fail — failed Flows disappear silently otherwise.
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