Workflow

What It Is

Workflow is ServiceNow's legacy visual automation engine that orchestrates multi-step business processes by connecting discrete activities in a graphical interface. Unlike Business Rules that fire instantly on record changes, Workflow manages sequential operations that may span minutes, hours, or days — approval chains, complex integrations, user notifications, and any process requiring conditional branching or human intervention. The engine executes activities one at a time based on defined transitions, maintaining state throughout the entire process lifecycle and providing administrators complete visibility into where each workflow instance currently stands.

Architecturally, Workflow lives in the Workflow application within the platform's automation layer, sitting between the database layer and the presentation layer. The engine operates through the wf_workflow table for definitions and the wf_context table for runtime execution state, with individual activities stored in wf_activity and their execution history tracked in wf_executing. The Workflow Engine runs as a scheduled job that continuously polls for workflow contexts ready for the next activity, making it fundamentally different from the synchronous execution model used by Business Rules and other immediate automation.

The underlying execution environment relies on workflow activities — discrete, reusable components that perform specific operations like sending emails, creating records, running scripts, or waiting for approvals. Each activity contains input variables, output variables, and transition conditions that determine which activity fires next. The workflow engine maintains a context object throughout execution that stores all variable values and tracks the current state, allowing workflows to pause indefinitely at approval activities or timer activities without consuming system resources. This stateful execution model enables complex scenarios impossible with other automation tools, such as escalation chains that modify behavior based on time elapsed or approval processes that route differently based on accumulated responses.

You cannot function without Workflow in scenarios requiring human interaction within automated processes, complex approval chains with dynamic routing, or any process that must pause execution waiting for external events. ITSM approval processes, procurement workflows, employee onboarding sequences, and vendor management processes all depend on Workflow's ability to maintain state across extended timeframes. Flow Designer cannot replace Workflow for approval-heavy processes or scenarios requiring the extensive library of pre-built activities that ship with ServiceNow. Most importantly, any process requiring precise control over execution timing — such as SLA-driven escalations or compliance workflows with mandatory waiting periods — needs Workflow's timer and scheduling capabilities that other automation tools lack.

Platform administrators typically manage workflow definitions and monitor execution, while developers create custom activities and complex conditional logic through scripted activities. System administrators control the workflow engine itself through System Properties and scheduled jobs, but day-to-day workflow management falls to process owners who understand the business logic. Unlike Flow Designer where process owners can build their own flows, Workflow requires technical knowledge to construct properly, making it primarily an administrator and developer tool. The relationship between these roles becomes critical during troubleshooting, as workflow failures often require both technical debugging skills and business process understanding to resolve effectively.

Recent ServiceNow releases have maintained Workflow functionality while steering new development toward Flow Designer, though no deprecation timeline exists. Vancouver and later versions include enhanced monitoring capabilities and improved error handling for workflow execution, but the core engine remains unchanged. The platform continues shipping new workflow activities in specialized applications like HR Service Delivery and Customer Service Management, indicating continued investment despite Flow Designer's prominence. However, new instances show a clear preference for Flow Designer in out-of-box processes, with Workflow reserved for scenarios requiring its specific capabilities.

Where to Find and Configure It

Navigate to Workflow > Workflow Editor to access the primary workflow design interface where you create, modify, and test workflow definitions. Use Workflow > Workflow Admin to monitor running workflows, troubleshoot stuck contexts, and manage workflow engine settings. Access workflow definitions directly through Workflow > Workflows for list-based management and bulk operations.

Find workflow activities at Workflow > Activities to browse, create, or modify the building blocks used in workflow design. Monitor active workflow execution through Workflow > Active Workflows to see real-time execution status and identify performance issues. Access workflow contexts directly via System Logs > Workflow Contexts for detailed troubleshooting and historical execution data.

Workflow operates identically in scoped and global applications, with scoped workflows accessing only their application's tables and activities unless explicitly granted cross-scope access. Studio includes workflow design capabilities through Create Application File > Workflow, though the full Workflow Editor provides more functionality. App Engine Studio does not support workflow creation, reflecting ServiceNow's strategic direction toward Flow Designer for new development. Related tables include sys_trigger for workflow launch conditions and task_rel_approval for approval activity integration.

How It Works Step by Step

The Workflow engine operates through a polling mechanism that continuously checks for workflow contexts ready for execution. When a record meets workflow launch conditions, the engine creates a workflow context containing all variable values and execution state, then begins processing activities sequentially based on defined transitions. Each activity executes, potentially modifying variables or performing external actions, then signals completion to advance the workflow to the next activity. The engine maintains persistent state throughout this process, allowing workflows to pause at activities requiring external input and resume exactly where they stopped.

Activity execution follows a strict input-process-output pattern where the engine first populates input variables from the workflow context, executes the activity's core function, then updates the context with output variables before evaluating transition conditions. Timer activities and approval activities can pause execution indefinitely without consuming resources, as the engine simply marks the context as waiting and moves to other ready contexts. Error handling occurs at both the activity level and workflow level, with failed activities either stopping execution, following error transitions, or triggering rollback procedures depending on configuration.

The Execution Order

1. Trigger evaluation determines if workflow launch conditions are met on record insert, update, or manual initiation
2. Workflow context creation initializes all variables and sets the current activity to the workflow's start activity
3. Engine polling identifies contexts ready for execution based on activity state and timing conditions
4. Input variable population transfers values from workflow context to current activity's input parameters
5. Activity execution performs the specific operation (email, approval, script, etc.) defined by the activity type
6. Output variable assignment updates workflow context with values produced during activity execution
7. Transition evaluation determines the next activity based on conditions and activity completion status
8. Context state update sets the workflow to the next activity or marks completion if no transitions match

// Common script activity pattern for workflow variable manipulation
// Access current record through workflow.current
// Read workflow variables using workflow.variables.variable_name
// Set workflow variables using workflow.variables.variable_name = value

// Example: Calculate priority based on business logic
var priority = 'Low';
var impact = workflow.current.impact.toString();
var urgency = workflow.current.urgency.toString();

if (impact == '1' && urgency == '1') {
    priority = 'Critical';
} else if (impact == '1' || urgency == '1') {
    priority = 'High';
} else if (impact == '2' && urgency == '2') {
    priority = 'Medium';
}

// Set workflow variable for use in subsequent activities
workflow.variables.calculated_priority = priority;
workflow.info('Priority calculated as: ' + priority);

Real-World Scenarios

Multi-Level Incident Escalation with Time-Based Routing

Your organization requires Priority 1 incidents to escalate automatically through three management levels if not resolved within specific timeframes: 30 minutes to team lead, 60 minutes to department manager, 90 minutes to VP. Each escalation must send notifications to the next level while maintaining visibility for previous levels, and the process must stop immediately if the incident gets resolved at any point.

Create a workflow with Table: incident and Condition: priority=1 AND state!=6 AND state!=7. Add three Timer activities set to 30, 60, and 90 minutes respectively, each followed by a "Check if Still Open" activity that exits the workflow if the incident is resolved. Connect each timer to a "Send Notification" activity targeting the appropriate management level using dynamic recipient lists based on the assignment group's manager hierarchy. Set up "Cancel Workflow" activities on all open transitions to ensure the process stops when incidents reach resolved states.

Watch for timezone issues with timer activities as they use server time, not user time zones. Ensure your condition logic accounts for incidents that might be closed and reopened, as this could trigger duplicate workflows. Test thoroughly with incident state changes during execution, as manual state updates can bypass your workflow's exit conditions if not properly configured in the activity transitions.

Purchase Request Approval with Dynamic Routing and Parallel Processing

Purchase requests need approval from both the requestor's manager and the finance department, but the routing logic depends on amount: under $1,000 requires only manager approval, $1,000-$5,000 needs manager plus finance approval in parallel, over $5,000 requires sequential approvals from manager, finance, and procurement. The workflow must handle rejection at any stage and route back to the requestor for modifications with specific feedback about which approval failed.

Build the workflow using a "Script" activity immediately after start to set routing variables based on the amount field, then use "Switch" activities to branch to appropriate approval paths. For parallel approvals, create separate "Approval" activities for manager and finance with identical timing, then use a "Join" activity to wait for both completions before proceeding. Set up "Approval - User" activities with Groups or Users: javascript:current.requested_for.manager for manager approval and specific finance group for finance approval. Configure rejection transitions to route to a "Notification" activity that sends details to the requestor with specific rejection reasons, then ends the workflow with state updates.

Join activities can cause workflow deadlock if one approval path fails while another succeeds, so always include timeout transitions on join activities. Test manager hierarchy resolution thoroughly as empty manager fields will cause approval activities to fail silently. Consider using workflow variables to track which approvals have completed when debugging parallel approval issues, as the execution log can be difficult to interpret with multiple simultaneous activities.

Employee Onboarding with Cross-Department Coordination

New employee onboarding requires coordination between HR, IT, and Facilities with specific dependencies: HR must complete background verification before IT can provision accounts, but Facilities can prepare workspace in parallel. Each department needs task assignments with different SLAs (HR: 3 days, IT: 1 day, Facilities: 2 days), and the process must automatically escalate overdue tasks while sending weekly status updates to the hiring manager until all tasks complete.

Design the workflow with parallel branches for HR and Facilities tasks, while IT tasks wait for HR completion through a "Wait for Condition" activity checking HR task state. Use "Create Task" activities to generate specific tasks for each department with appropriate assignment groups and SLA values. Set up "Timer" activities for escalation (daily checks) connected to "Script" activities that evaluate task SLA breach conditions and send escalation emails accordingly. Create a "Timer" activity set to weekly intervals that triggers "Send Notification" activities to hiring managers with current status. Use "Wait for Condition" activities to pause workflow progress until all required tasks reach Complete state, then conclude with a final notification and workflow completion.

Wait for Condition activities can create infinite loops if the condition never becomes true, so always include timeout transitions with appropriate fallback actions. Task creation activities need proper error handling for cases where assignment groups don't exist or are empty. Monitor workflow contexts carefully during testing as complex dependencies can cause workflows to stall indefinitely if any single condition check fails, requiring manual intervention to resolve stuck processes.

The Classic Mistake

// BAD: Synchronous REST call activity
var request = new sn_ws.RESTMessageV2('External API', 'GET User');
request.setStringParameterNoEscape('user_id', current.sys_id);
var response = request.execute();

// This blocks the entire workflow thread
var responseBody = response.getBody();
var status = response.getStatusCode();

// If external system is slow or down, workflow times out
if (status == 200) {
    current.external_data = responseBody;
    current.update();
}

// Other activities in workflow cannot proceed
workflow.scratchpad.api_result = responseBody;

This fails because synchronous activities block the entire workflow execution thread, and workflows have a 10-minute execution timeout by default. Users see workflows stuck in Executing state indefinitely, and the wf_executing table shows activities that never complete. ServiceNow internally queues the workflow in the scheduler, but the blocking operation prevents the workflow engine from proceeding to subsequent activities or processing other workflows in the queue. The timeout isn't obvious because failed workflows often remain in Executing state rather than transitioning to Finished with an error.

// GOOD: Asynchronous with timer activity sequence
// Activity 1: Start async operation
var request = new sn_ws.RESTMessageV2('External API', 'GET User');
request.setStringParameterNoEscape('user_id', current.sys_id);

// Store operation ID for tracking
workflow.scratchpad.operation_id = gs.generateGUID();
workflow.scratchpad.start_time = gs.nowDateTime();

// Start async operation, don't wait
request.executeAsync();

// Activity 2: Timer (30 seconds)
// Activity 3: Check completion script
var elapsed = gs.dateDiff(workflow.scratchpad.start_time, gs.nowDateTime(), true);
if (elapsed > 300) { // 5 minute max
    workflow.scratchpad.timeout = true;
} else {
    // Check if operation completed
    workflow.scratchpad.check_again = !isOperationComplete();
}

When to Use This vs Alternatives

Use Workflow only when you have complex legacy automations already built and stable, or when you need the specific visual debugging capabilities that Flow Designer lacks. The visual workflow editor provides better step-by-step execution tracking than Flow Designer's execution details, making it valuable for troubleshooting intricate multi-branch processes.

When Workflow is the Right Choice

Stick with Workflow when you have existing complex approval chains with custom activities that would require significant redevelopment in Flow Designer. Workflow's Begin, End, and Join activities provide more granular control over parallel execution paths than Flow Designer's limited parallel processing. Use it when you need the wf_executing table's detailed activity state tracking for compliance or audit requirements that Flow Designer's execution history cannot satisfy.

When to Use Flow Designer Instead

Choose Flow Designer for any new automation requiring external system integration, as its native REST steps and error handling surpass Workflow's capabilities. Flow Designer's subflow reusability and spoke integration make it superior for building maintainable automations across multiple applications. Switch to Flow Designer when your workflow relies heavily on Run Script activities, since Flow Designer's script steps provide better variable scoping and debugging.

When You Need Both

Use Workflow for user-facing approval processes where you need the approval activity's built-in functionality, then trigger Flow Designer subflows for the technical integration work. This hybrid approach leverages Workflow's superior approval handling while using Flow Designer for modern API integrations. You can trigger flows from workflow Run Script activities using sn_fd.FlowAPI.startFlow() for complex scenarios requiring both paradigms.

Platform Interactions & Side Effects

• Business Rules execute before workflow activities when triggered by record updates, but workflow script activities can modify records and re-trigger business rules, creating potential infinite loops
• Creates records in wf_context (workflow instances), wf_executing (active activities), and wf_history (completed activities) tables
• Workflow variables stored in wf_context.scratchpad field are limited to 4000 characters and don't compress automatically, causing truncation issues with large datasets
• ACLs apply to workflow script activities when accessing records, but the workflow engine runs with elevated privileges, potentially bypassing field-level security unexpectedly
• Update Sets capture workflow versions but not workflow context data, causing deployment issues when moving workflows with active instances between environments
• Notifications triggered from workflow activities inherit the workflow's execution context, causing ${current} mail script variables to reference the workflow's target record rather than notification recipient
• Scheduler jobs process workflow activities, and high workflow volume can overwhelm the scheduler queue, delaying other scheduled jobs including imports and maintenance tasks
• Transform Maps and Import Sets ignore workflow triggers by default unless ignore_workflow parameter is explicitly set to false in the transform script
• Session timeout doesn't apply to workflow execution, but workflow activities that create UI actions or generate URLs may reference expired sessions, causing authentication failures
• Database locks held by workflow script activities can cause deadlocks with concurrent user transactions, particularly when workflows update parent records while users modify related records

Debugging and Troubleshooting

The most common failure symptoms include workflows stuck in Executing state indefinitely, users reporting missing workflow-generated emails or record updates, and workflows that appear to skip activities without explanation. Users typically see incomplete approval processes or automation that partially executes then stops, while administrators see growing numbers of wf_executing records with old timestamps. Performance issues manifest as slow record saves or delayed scheduled job execution when workflows consume excessive scheduler resources.

Check System Log > System Log > All for workflow execution errors, particularly JavaScript errors from Run Script activities. Navigate to Workflow > Workflow Contexts to examine individual workflow instances and their execution state. The wf_executing table shows currently active activities with their start times and can reveal blocked or abandoned activities. Enable debug logging by setting glide.workflow.log_level system property to debug for detailed activity execution logging.

Look for error messages like "Workflow activity timed out", "ReferenceError: current is not defined" in script activities, or "Workflow cancelled due to updated record" when record changes invalidate workflow conditions. Debug output shows activity transitions as "Activity 'ActivityName' completed with result 'yes'" or "Activity 'ActivityName' waiting for condition". Missing transitions appear as activities completing but no subsequent activities executing, indicating condition evaluation failures or missing workflow paths.

Diagnostic Checklist:

• Query wf_executing table filtered by workflow name and check Started field for activities older than expected completion time
• Verify workflow conditions and transitions by testing them manually in background scripts with the same record context
• Check glide.workflow.max_executing system property to ensure workflow queue isn't throttled (default 500)
• Examine scratchpad contents in workflow context record for variable corruption or size limit violations
• Review scheduled job queue in System Scheduler > Scheduled Jobs > Today's Scheduled Jobs for workflow backlog
• Test workflow manually from workflow editor using Test button with known problematic record
• Cancel stuck workflows using workflow.cancel() method or bulk cancel from Workflow Contexts list

Quick Reference

• Default workflow timeout is 600 seconds (10 minutes) controlled by glide.workflow.timeout system property
• Maximum 500 concurrent workflow activities by default (glide.workflow.max_executing), additional workflows queue until slots available
• Workflow scratchpad field has 4000-character limit and truncates silently, losing data without error messages
• Publishing new workflow versions automatically cancels all running instances of previous version unless Leave running option selected
• Approval activities create sysapproval_approver records automatically, but deleting approval records doesn't resume waiting workflows
• Timer activities consume scheduler resources even when waiting, and 1000+ concurrent timers can impact system performance
• Workflow variables beginning with current. reference the workflow's target record, not the current user's session record
• Workflow contexts remain in wf_context table indefinitely unless manually cleaned up or purged by scheduled maintenance jobs
• Condition fields support javascript: prefix for complex expressions, but syntax errors cause activities to never execute without obvious failure indication
• Workflows triggered by business rules execute asynchronously by default, but Run synchronously checkbox forces immediate execution within the business rule transaction