Flow Designer

What It Is

Flow Designer is ServiceNow's graphical workflow automation platform that executes business logic through a visual canvas of connected Actions and Subflows. It replaced the legacy Workflow editor starting in Kingston, providing a more maintainable and performant approach to automating processes across ServiceNow applications. Unlike traditional workflows that compile to activities, Flow Designer operates through a runtime engine that interprets flow definitions stored in the sys_hub_flow table, executing each step as discrete operations with full data context preservation.

Architecturally, Flow Designer sits within the Process Automation application as part of ServiceNow's automation layer, operating above the database but below the user interface. Flows execute server-side through the Flow Engine, which runs in the ServiceNow application context with full access to GlideRecord APIs, script includes, and platform services. The execution context maintains data pill connections between Actions, allowing complex data transformations and business logic chains that span multiple tables and applications. Flow Designer integrates directly with Action Framework, meaning every flow step leverages the same reusable Action catalog used by Virtual Agent, Orchestration, and other automation tools.

The underlying data model centers on flow definitions (sys_hub_flow), flow contexts (sys_hub_flow_context), and execution steps (sys_hub_step_context). Each flow execution creates a context record that tracks the complete data state throughout the flow run, enabling debugging, rollback capabilities, and audit trails that traditional business rules cannot provide. The Flow Engine maintains transaction boundaries per flow execution, ensuring data consistency while allowing flows to span multiple database operations and external system calls.

You cannot function without Flow Designer in scenarios requiring multi-step automation with error handling, complex approval chains with dynamic routing, or any process that needs visual documentation alongside execution. Traditional business rules fail when you need to orchestrate sequences like "create child records, send notifications, wait for approvals, then update parent records based on approval outcomes." Flow Designer becomes essential for integrations requiring retry logic, transformation chains that span multiple record types, or any automation that business users need to understand and modify without diving into JavaScript code.

Platform owners typically enable Flow Designer at the instance level and manage the Action catalog, while application developers build flows within their scoped applications using Actions appropriate to their scope. System administrators configure triggers and maintain flow execution monitoring, but the actual flow logic often falls to business analysts or citizen developers who can work with the visual interface. The governance model differs significantly from business rules—flows can be built by non-developers but still require technical oversight for performance and security implications.

Recent releases have significantly enhanced Flow Designer's capabilities, with Vancouver introducing improved error handling and execution performance optimizations. Xanadu added advanced data pill manipulation and better integration with RPA Hub, while the current release includes enhanced debugging tools and execution context preservation. The Action catalog has expanded dramatically, with ServiceNow now providing hundreds of pre-built Actions compared to the basic set available in Kingston, reducing the need for custom scripted Actions in most implementations.

Where to Find and Configure It

Access Flow Designer through Process Automation > Flow Designer where you create, edit, and manage all flows and subflows. The main interface provides the visual canvas, Action palette, and flow execution testing capabilities.

• Flow definitions and execution history: Process Automation > Flow Designer > Flow Executions for monitoring and debugging active and completed flow runs
• Action catalog management: Process Automation > Actions to create custom Actions or modify existing ones
• Subflow library: Process Automation > Subflows for reusable flow components that can be called from multiple flows
• Studio integration: System Applications > Studio where flows appear as application artifacts alongside other customizations
• Flow trigger configuration: System Definition > Tables then select a table and configure Business Rules to launch flows

How It Works Step by Step

Flow Designer operates through a runtime engine that interprets flow definitions rather than compiling them into executable code. When a trigger fires (typically a business rule or scheduled job), the Flow Engine creates a new flow context record and begins executing the flow definition step by step. Each Action in the flow receives input data through data pills from previous steps, executes its defined logic, then outputs results as new data pills for subsequent Actions.

The Flow Engine maintains complete execution state throughout the flow run, storing intermediate results in the flow context and handling error conditions through defined error paths or default error handling. Unlike business rules that execute synchronously within database transactions, flows can execute asynchronously, pause for external events like approvals, and resume execution while maintaining their data context. This execution model enables complex orchestrations that span multiple database transactions and external system interactions while preserving data consistency.

Data pill connections represent the flow's data pipeline, where each Action can access outputs from any previous Action in the same flow execution. The engine resolves data pill references at runtime, performing type checking and data transformation as needed. Flow variables provide temporary storage within the flow execution, while flow inputs allow external systems or triggers to pass initial data into the flow.

The Execution Order

1. Trigger fires (business rule, scheduled job, or manual execution) and identifies the target flow
2. Flow Engine creates a new flow context record and initializes flow inputs with trigger data
3. Engine evaluates flow conditions and determines the first Action to execute
4. Each Action receives its input data pills, executes its logic, and produces output data pills
5. Engine follows flow connections to the next Action, evaluating any conditional logic
6. Process continues until reaching a flow end point, error condition, or wait state
7. Flow context updates with completion status and final output data pills

// Business Rule to trigger a flow on Incident creation
(function executeRule(current, previous /*null when async*/) {
    
    var flowInputs = {
        'record': current.getUniqueValue(),
        'table': current.getTableName(),
        'priority': current.priority.toString(),
        'assigned_to': current.assigned_to.toString()
    };
    
    // Trigger the flow with input data
    var flowAPI = new sn_fd.FlowAPI();
    flowAPI.startFlow(
        '3f5e8d2a1b77341057c8393c604bcb23', // Flow sys_id
        flowInputs
    );
    
})(current, previous);

Real-World Scenarios

Automated Incident Escalation with Approval Chain

High-priority incidents need automatic escalation to management after 2 hours, but only if the assigned group hasn't updated the incident and no one has requested additional time. This requires checking multiple conditions, sending notifications, creating approval requests, and updating records based on approval outcomes.

Create a scheduled flow that queries incidents created 2 hours ago with priority = 1 and state = New. Use a For Each action to process each incident, then add a Lookup Records action to check for work notes in the last 2 hours. Connect a conditional flow logic that branches to either "Send escalation notification" or "Request approval for extension." After approval actions complete, use an Update Record action to modify the incident priority and assignment based on the approval decision. Add error handling actions to log failures and send admin notifications when Actions fail.

Multi-System User Onboarding with Rollback

New employee records trigger user account creation across Active Directory, email systems, and application access, but if any system fails, all previous accounts need to be cleaned up. Manual rollback tracking is error-prone and time-consuming when integrations span multiple external systems.

Build the flow with sequential integration Actions for each system (Create AD User, Create Email Account, Assign Application Access), storing each system's response data in flow variables like ad_user_id and email_account_id. Connect each Action's error output to a rollback subflow that uses the stored IDs to delete previously created accounts in reverse order. Use conditional logic to check which systems completed successfully before attempting cleanup. Add a final notification Action that reports the onboarding status and any rollback actions taken.

Dynamic Service Catalog Fulfillment Based on Location

Service catalog requests need different fulfillment processes based on the requester's location, department, and request type, with some requiring manager approval, others requiring vendor notifications, and some handled entirely by automated provisioning. Business rules can't handle this complexity without becoming unmaintainable.

Create a flow triggered by catalog task creation that uses Lookup Records to get the requester's location and department data. Build a series of conditional branches using If/Else logic actions that evaluate combinations like location = 'Europe' AND department = 'Finance'. Connect each branch to different subflows for approval routing (manager approval subflow), vendor notification (send email with specific templates), or automated fulfillment (create records and assign to groups). Use data pills to pass request details into each subflow, and create a final convergence point that updates the original request with processing status and expected completion time.

The Classic Mistake

The typical mistake happens when admins drag a For Each Item in Data Array action onto the canvas and feed it an unfiltered GlideRecord query or REST response. They configure the Data Array field to something like data.table_api.getRecords.result from a Look Up Records action that returns 500+ records. Inside the loop, they add actions like Update Record or Create Record without any batching strategy. The flow appears to work fine in testing with small datasets, so it gets deployed to production.

// Look Up Records action configuration:
// Table: incident
// Condition: active=true
// Maximum records: 1000 (or blank)
// Result: data.lookupincidents

// For Each Item configuration:
// Data Array: data.lookupincidents.getRecords.result
// Item: currentincident

// Inside the loop - Update Record action:
// Table: incident
// Record: data.currentincident.sys_id
// Fields to Update:
//   state: 6 (Resolved)
//   resolution_notes: "Bulk resolved by automation"
//   resolved_by: gs.getUserID()
//   resolved_at: gs.nowDateTime()

This fails catastrophically because Flow Designer executes every iteration synchronously within the same transaction context, and each database operation compounds the execution time. Users see flows that never complete or take 10+ minutes to finish, while system administrators see timeout errors in System Log > Flow Designer. ServiceNow's transaction timeout (default 600 seconds) kills the flow execution, leaving partial updates and inconsistent data states. The mistake is non-obvious because small test datasets complete quickly, masking the scalability problem until production volumes hit.

// Main Flow - Look Up Records action:
// Table: incident
// Condition: active=true
// Maximum records: 50
// Order by: sys_created_on

// Call Subflow action:
// Subflow: "Batch Process Incidents"
// Inputs: batch_records = data.lookupincidents.getRecords.result

// Subflow "Batch Process Incidents":
// Input: batch_records (array)
// For Each Item: data.batch_records
// Inside loop: Update Record action (same config as above)

// Schedule next batch with Create Event action:
// Event: "process.next.incident.batch"
// Condition: data.lookupincidents.getRecords.result.length == 50
// Scheduled for: 30 seconds from now

When to Use This vs Alternatives

Flow Designer is the correct choice for multi-step business processes that require human interaction, external system integration, or complex branching logic where you need visual documentation and business user comprehension. Use it when stakeholders need to understand, modify, or approve the automation logic without reading code.

When Flow Designer is Right

Choose flows for approval workflows, ServiceNow-to-external system integrations, and any process requiring wait conditions or human input. Business Rules can't pause execution or wait for external responses, while Scheduled Jobs lack the trigger flexibility and visual troubleshooting that flows provide. Flow Designer excels when you need audit trails of decision paths and variable states throughout process execution.

When to Use Something Else

Use Business Rules for simple field calculations, data validation, or any logic that must execute synchronously within the database transaction. Choose Scheduled Jobs for bulk data processing, maintenance tasks, or any automation that processes thousands of records. Opt for Script Includes when building reusable logic libraries, and use Transform Maps for data imports where field mapping and error handling are primary concerns.

When You Need Both

Combine Business Rules with Flow Designer when you need immediate field updates plus downstream process orchestration—the Business Rule handles data integrity while the flow manages notifications and external system updates. Use flows with Scheduled Jobs when you need event-driven triggers to queue work for batch processing later. Pair flows with Script Includes when complex calculations or external API calls need to be tested independently and reused across multiple flows.

Platform Interactions & Side Effects

• Creates records in sys_flow_context and sys_flow_step tables for every execution, persisting variable states and step outcomes—these tables grow rapidly in high-volume environments
• Business Rules still fire on records created or updated by flow actions, potentially creating infinite loops if the Business Rule triggers the same flow
• ACLs are enforced using the flow runner's permissions (typically system user for system-triggered flows), not the initiating user's permissions, which can bypass intended security controls
• Update Sets capture flow definitions but not runtime execution data—migrating flows between instances doesn't transfer context or step history
• Notifications triggered by flow actions inherit the flow's context, so mail_script variables may not resolve as expected if the flow user lacks proper field access
• Flow executions consume session resources and maintain database connections until completion, impacting system performance during long-running or high-volume flows
• Transform Map scripts and Import Set processing ignore flow triggers—data loaded through imports won't fire flow-based automations even if Business Rule triggers are configured
• Cache invalidation occurs when flows modify records, but flow variables themselves aren't cached, leading to repeated database queries for the same data within flow execution
• MID Server capabilities in flow actions execute with the MID Server's security context, not the ServiceNow user's context, potentially accessing systems that the user shouldn't reach
• Audit records in sys_audit show flow-initiated changes with user_name as the flow runner, obscuring the actual business user who initiated the process

Debugging and Troubleshooting

The most common failure symptoms include flows that start but never complete (stuck in In Progress state), actions that skip unexpectedly showing Skipped status in execution details, and flows that trigger repeatedly in rapid succession. Users report that expected actions don't occur—records aren't updated, notifications aren't sent, or external systems don't receive expected data. Administrators see timeout errors, script errors in flow steps, or flows consuming excessive processing time in system monitoring dashboards.

Start debugging in Process Automation > Flow Designer > Executions to see execution history and step-by-step results. Check System Log > All filtered by source=Flow Designer for script errors and system-level failures. For trigger issues, examine the sys_flow_context table directly to see if flows are starting with expected trigger data. Look for error messages like "ReferenceError: data.trigger.current is undefined" indicating trigger configuration problems, or "TypeError: Cannot read property of undefined" suggesting variable mapping issues between steps.

Enable debug logging by setting com.glide.hub.flow_engine.log_level system property to debug for detailed execution logging, but remember to reset it to info after troubleshooting to avoid log pollution. Use the Test button in Flow Designer with specific test data to isolate problems, and check variable pill values by clicking each step in the execution timeline to see exact data passed between actions.

Diagnostic Checklist:

• Verify the trigger condition by checking recent executions in Flow Designer > Executions—if no executions appear, the trigger isn't firing
• Check the flow's Run As configuration and verify that user has required roles for all actions performed
• Examine each Skipped action by clicking it in execution details and reviewing the condition evaluation
• Test variable pill data by adding temporary Log Message actions to output variable values to System Log
• Look for infinite loops by checking if the same flow context executes repeatedly with identical trigger data
• Validate external system connectivity by testing REST or SOAP actions independently using REST API Explorer
• Review flow version history if problems started recently—compare current version against last working version in More actions > Version History

Quick Reference

• Flow execution timeout is controlled by com.glide.hub.flow_engine.timeout system property, defaulting to 600 seconds—exceeding this kills the execution
• Maximum 1,000 variables per flow execution—exceeding this limit causes "Variable limit exceeded" errors and flow failure
• Variable pill data persists in sys_flow_context.data as JSON—large datasets bloat this field and impact database performance
• Subflows don't inherit parent flow's trigger data automatically—you must explicitly pass trigger variables as inputs
• "Created" trigger fires after Business Rules complete, while "Before" trigger fires before Business Rules—timing affects data availability
• Flow Designer actions are atomic—if one action in a flow fails, previous actions don't automatically rollback unless explicitly configured
• REST actions timeout after 30 seconds by default—configure longer timeouts for slow external systems using the Request Timeout field
• Custom table triggers require flow_designer role on the table's ACLs—without this, flows won't see record changes
• Flow Designer ignores choice field integer values—always use display values ("Open", "Closed") rather than numeric values (1, 7) in conditions
• Deactivated flows still appear in execution history and can be accidentally reactivated—use Retire action to permanently disable flows