Error Handler

What It Is

Error Handler is a Flow Designer component that intercepts exceptions and failures from preceding flow activities, allowing you to define custom error processing instead of letting the entire flow crash. When any activity in your flow fails—whether it's a REST call timing out, a record lookup returning no results when one is expected, or a script throwing an exception—the Error Handler catches that failure and executes your defined error recovery logic. Without Error Handlers, flow failures immediately terminate execution and often leave users staring at generic error messages while your business process remains incomplete.

Error Handler lives within the Flow Designer application (com.glideapp.servicecatalog.workflow.datadriven) as a specialized flow component that plugs into ServiceNow's flow execution engine. It operates at the same architectural level as other flow activities like Create Record, Lookup Records, or REST steps, but serves a fundamentally different purpose—error interception rather than business logic execution. The component integrates directly with ServiceNow's JavaScript engine and can access the same server-side APIs available to Business Rules and Script Includes.

The Error Handler relates to ServiceNow's flow execution context through the sys_flow_context table, where each flow execution maintains its state and variable values. When an error occurs, the handler receives detailed error information including the failing activity name, error message, and current flow context data. This allows you to make intelligent decisions about error recovery based on what specifically failed and what data was available at the time of failure. The handler can modify flow variables, create log records, send notifications, or even trigger compensating transactions to undo partially completed work.

You cannot function without Error Handlers in any production flow that integrates with external systems, processes bulk data, or handles user-initiated requests where failure means business impact. Consider a flow that provisions user accounts across multiple systems—if the Active Directory integration fails but the ServiceNow account was already created, you need error handling to either roll back the ServiceNow changes or queue the AD creation for retry. Similarly, flows processing employee onboarding, financial approvals, or customer service requests require graceful error handling to maintain data integrity and provide meaningful feedback to users rather than cryptic system errors.

Platform owners and developers typically design Error Handler logic, while application admins configure the specific error responses and notifications. The Error Handler requires JavaScript knowledge to implement custom logic, making it primarily a developer concern, but admins need to understand how to monitor error handler execution and modify error notification recipients or retry parameters. Business stakeholders define the error handling requirements—what should happen when integrations fail, how users should be notified, and what data recovery procedures are acceptable.

Recent ServiceNow releases have enhanced Error Handler capabilities with improved error context information and better integration with ServiceNow's logging framework. Vancouver introduced more detailed error objects that include stack traces and activity-specific error codes, while Xanadu added support for conditional error handling based on error type. The Flow Execution Details interface was also improved to provide better visibility into error handler execution, showing exactly which errors were caught and how they were processed.

Where to Find and Configure It

Navigate to Process Automation > Flow Designer to access the primary Flow Designer interface where you add Error Handler components to existing flows. Within any flow, click Add an Action, Flow Logic, or Subflow, then select Flow Logic > Error Handler to insert the error handling component.

In App Engine Studio, access Error Handlers through Logic and automation > Flows where the component selection interface mirrors the standard Flow Designer. For scoped applications, Error Handlers inherit the application scope and can only access tables and APIs available within that scope, while global Error Handlers can access any platform resource.

Monitor Error Handler execution through Process Automation > Flow Designer > Flow Executions where each execution record shows whether error handlers fired and what actions they performed. The sys_flow_context table contains the underlying execution data, while System Logs > System Log > Flow Designer captures detailed error handler logging output.

How It Works Step by Step

Error Handler operates through ServiceNow's flow execution engine exception handling mechanism, monitoring all activities that execute after its placement in the flow sequence. When any subsequent activity throws an exception—whether it's a JavaScript error, a failed REST call, or a validation failure—the flow engine immediately transfers control to the nearest Error Handler instead of terminating the entire flow. The Error Handler receives a comprehensive error object containing the exception details, the failing activity name, and complete access to all current flow variables and context data.

The Error Handler component executes within the same server-side JavaScript context as the failed activity, providing access to the full ServiceNow API including GlideRecord, GlideSystem, and custom Script Includes. Your error handling script can examine the error details, modify flow variables, create or update records, send notifications, and even make external API calls for error reporting. After the Error Handler completes its processing, flow execution can either continue with the next activity in sequence or terminate gracefully based on your error handling logic.

The Execution Order

1. Flow execution proceeds normally through activities until an exception occurs in any activity following the Error Handler placement
2. ServiceNow's flow engine catches the exception and identifies the nearest Error Handler component in the flow sequence
3. Flow execution transfers to the Error Handler, which receives an error object containing exception details, failing activity name, and error message
4. Error Handler script executes with full access to flow variables and ServiceNow server-side APIs
5. Based on error handling logic, flow execution either continues with the next activity or terminates with a controlled completion status
6. Flow execution details are logged to the sys_flow_context table with error handler execution results and any custom logging output

// Access error details from the caught exception
var errorMessage = fd_data.error.message;
var failingActivity = fd_data.error.activity_name;
var errorCode = fd_data.error.error_code;

// Log detailed error information
gs.error('Flow error in activity: ' + failingActivity + ', Message: ' + errorMessage);

// Check if this is a retryable error
if (errorCode == 'CONNECTION_TIMEOUT' || errorCode == 'SERVICE_UNAVAILABLE') {
    // Set retry flag for later processing
    fd_data.should_retry = true;
    fd_data.retry_count = (fd_data.retry_count || 0) + 1;
    
    // Create incident for tracking if retry limit exceeded
    if (fd_data.retry_count > 3) {
        var inc = new GlideRecord('incident');
        inc.initialize();
        inc.short_description = 'Flow integration failure: ' + failingActivity;
        inc.description = 'Error: ' + errorMessage + '\nFlow: ' + fd_data.trigger.flow_name;
        inc.insert();
    }
}

Real-World Scenarios

Handling External API Integration Failures

Your employee onboarding flow creates accounts in ServiceNow, Active Directory, and Office 365, but the Office 365 API frequently times out during peak hours. When this integration fails, you need to complete the other provisioning steps and queue the Office 365 account creation for retry rather than forcing HR to restart the entire onboarding process.

Place the Error Handler before your Office 365 integration step and configure it to catch REST call failures. In the Error Handler script, check if the error is a timeout (fd_data.error.error_code == 'TIMEOUT'), then create a record in a custom retry queue table with the employee details and set fd_data.office365_failed = true. Use a subsequent If condition to skip Office 365-dependent activities when this flag is set, allowing the flow to complete successfully while logging the partial failure.

Data Validation Failure with User Notification

A request fulfillment flow processes user requests for software installations, but sometimes the requested software isn't in your approved catalog or the user's department lacks the proper licensing. Rather than showing users a cryptic "Record not found" error, you want to explain what went wrong and suggest alternatives.

Place an Error Handler after your software catalog lookup step. In the error script, use GlideRecord to search for similar software names (software.addQuery('name', 'CONTAINS', fd_data.requested_software)), then build a list of alternatives. Create a work note on the originating request item with a user-friendly message explaining the issue and listing the suggested alternatives, then set the request state to Pending Information so the user can respond with a valid selection.

Transaction Rollback for Multi-System Updates

Your change management flow updates configuration items in ServiceNow's CMDB, then pushes those changes to monitoring systems and backup schedules. If the monitoring system update fails after CMDB changes are committed, you need to revert the ServiceNow changes to maintain data consistency between systems.

Before making any changes, use a Lookup Records step to capture the original CI values in flow variables like fd_data.original_status and fd_data.original_environment. Place an Error Handler after your CMDB update but before the monitoring system integration. In the error handler, use an Update Record step to restore the original CI values, then create a change task assigned to the integration team with details about the rollback and the monitoring system error.

The Classic Mistake

Most admins treat Error Handlers like traditional try-catch blocks, placing them at the flow's end to "catch everything." They'll build a 15-step flow with REST calls, record lookups, and field updates, then drop a single Error Handler at step 16. When the REST call at step 3 fails, the flow dies immediately—the Error Handler never executes because the flow execution stops at the point of failure. The error gets logged in System Log > All with a generic "Flow execution stopped due to error" message, and users see broken functionality with no graceful handling.

This fails because ServiceNow's Flow Designer uses immediate error propagation—when an activity fails, execution stops at that exact step. The Error Handler must be positioned as the direct "On Error" path from each risky activity, not as a downstream catch-all. ServiceNow doesn't queue errors for later handling; it terminates the flow instance immediately and marks it as failed in the sys_flow_context table. This behavior is non-obvious because other platforms allow centralized error handling, but ServiceNow requires point-of-failure error routing.

Flow Structure:
1. Create Record [incident]
   └─ On Success: Continue to step 2
   └─ On Error: Error Handler ("Record Creation Failed")

2. REST Call [external system]
   └─ On Success: Continue to step 3  
   └─ On Error: Error Handler ("External System Unavailable")

3. Update Record [incident.state = 6]
   └─ On Success: Continue to step 4
   └─ On Error: Error Handler ("Update Failed")

4. Send Notification
   └─ On Success: End
   └─ On Error: Error Handler ("Notification Failed")

Each Error Handler:
- Logs specific error context
- Updates incident with appropriate state
- Sends admin notification if needed
- Continues to completion or terminates gracefully

When to Use This vs Alternatives

Error Handlers are the right choice when you need graceful failure handling within automated workflows where user experience and process continuity matter more than stopping on the first error. Use them when business processes must continue even if individual steps fail, and when you need different recovery actions based on where failures occur.

When Error Handlers Are Correct

Choose Error Handlers for user-facing flows where failure should trigger alternative actions rather than stopping entirely—like creating a task when automated assignment fails, or logging incidents when integrations are down. Business Rules can't provide this kind of conditional error recovery, and Script Actions lack the visual error path mapping that makes complex failure scenarios manageable. Error Handlers excel when you need different responses to different failure types within the same process.

When to Use Alternatives Instead

Use Business Rules with try-catch blocks for simple validation failures that should prevent record saves entirely—Error Handlers can't stop database commits that are already in progress. Choose Script Actions for complex error handling logic that requires extensive ServiceNow API access or when you need to manipulate multiple unrelated records based on failure conditions. For integration errors, consider Scheduled Jobs with retry logic instead of Error Handlers when timing and persistence matter more than immediate response.

When You Need Both Together

Combine Error Handlers with Business Rules when you need both data validation (Business Rule) and process continuation (Error Handler)—the Business Rule prevents bad data from entering the database while the Error Handler manages workflow failures gracefully. Use Error Handlers alongside Script Actions when the error handling itself is complex enough to require custom scripting, but you want the visual flow representation for process documentation. This combination works well for enterprise integrations where data integrity and process reliability are both critical.

Platform Interactions & Side Effects

• Creates execution records in sys_flow_context with state 'error_handled' instead of 'failed', affecting flow analytics and reporting dashboards
• Triggers Business Rules on any records created or updated within the Error Handler, potentially causing recursive flows if the same trigger conditions are met
• Writes detailed error context to syslog table with source 'Flow Designer' and level 'Error', creating audit trails for compliance requirements
• Inherits the same user context and ACL restrictions as the original flow, but impersonation within Error Handlers can bypass field-level security unexpectedly
• Prevents Event Registry from firing 'flow.failed' events, instead firing 'flow.error_handled' events that many monitoring integrations don't catch by default
• Extends flow execution time beyond the standard 5-minute timeout when error handling includes wait conditions or long-running Script Actions
• Notifications sent from Error Handlers bypass subscription filters and notification suppression rules, always delivering unless the user account is completely inactive
• Update Sets capture Error Handler configurations but not the error data mappings, causing deployment failures when target instances have different field schemas
• Session state remains active during error handling, keeping database connections open longer and potentially hitting connection pool limits during high-volume processing
• Flow variables set before the error remain available within Error Handlers, but variables from the failed step are empty or contain partial data, causing unexpected null reference errors

Debugging and Troubleshooting

The most common failure symptom is flows that appear to complete successfully but don't perform expected actions—users report "nothing happened" while the flow shows as completed in Execution Details. This occurs when Error Handlers catch failures but their own recovery actions fail silently. Admins see "Flow completed with handled errors" in the context record, but the business process remains broken. Another common symptom is flows that work in testing but fail in production due to different ACL contexts—Error Handlers inherit security restrictions that may not be apparent during development.

Check System Log > All for entries with source 'Flow Designer' and look for "Error Handler executed" messages that include the original error context. Enable the glide.flow.log_level system property set to 'debug' to capture variable states at error points. The sys_flow_context table stores execution details—look for records with state='error_handled' and examine the error_message field for root cause details.

Key error messages include "Error Handler activity failed" (the error handling itself broke), "Variable reference invalid in error context" (trying to use data from the failed step), and "Security constraints prevent error recovery action" (ACL issues within the Error Handler). Use the Flow Designer test mode with "Show execution details" enabled to trace exactly which error conditions trigger and whether Error Handler logic executes completely. Watch for timeout errors in Error Handlers—they have the same execution limits as regular flows but the timer doesn't reset when error handling begins.

Diagnostic Checklist:

• Verify Error Handler is connected as direct "On Error" path from failing activity, not downstream in flow sequence
• Check sys_flow_context.error_message field for actual failure reason before assuming Error Handler issues
• Test Error Handler recovery actions independently using Flow Designer test mode with simulated error conditions
• Validate that user context running the flow has necessary ACLs for all Error Handler activities
• Enable glide.flow.log_level=debug and examine variable states available within Error Handler scope
• Review Error Handler notification and record creation activities for their own potential failure points
• Check for recursive flow triggers caused by Error Handler record updates matching original flow trigger conditions

Quick Reference

• Error Handlers extend flow execution timeout from 5 minutes to 15 minutes when they include Wait or Timer conditions
• Variables from the failed step are not available in Error Handler scope—only flow-level and pre-failure step variables persist
• Maximum of 5 Error Handlers can execute in sequence before flow terminates with "Error handling limit exceeded" message
• Error context data in sys_flow_context.error_message is limited to 4000 characters and truncates stack traces
• REST call failures in Error Handlers don't trigger additional Error Handlers—they fail silently and log to syslog_transaction only
• Database transaction rollback affects all flow activities up to the error point, but Error Handler actions start a new transaction
• Subflow errors bubble up to parent flow Error Handlers only if the subflow itself doesn't handle them internally
• Clone operations in Update Sets don't preserve Error Handler variable mappings when field names differ between instances
• Flow execution records with handled errors count toward the 10,000 daily flow execution limit but appear as "successful" in analytics
• Integration Hub spokes called from Error Handlers use separate credential contexts and may fail authentication even when the main flow credentials work