Skip Activity

What It Is

Skip Activity is a Flow Designer execution control that marks individual flow activities as skipped instead of failed when expected conditions aren't met or required records don't exist. Rather than throwing an error that stops the entire flow, Skip Activity allows the flow to continue executing subsequent activities while maintaining a clear audit trail of what was bypassed. This mechanism is essential for building resilient automation that can handle real-world data inconsistencies and optional processing paths without requiring complex conditional logic wrapped around every activity.

Architecturally, Skip Activity lives within the Flow Designer engine in the Process Automation application as part of the flow execution framework. It operates at the activity level within the sys_hub_flow_base table family, where individual flow executions are tracked in sys_flow_context records with their corresponding activity states. The skip mechanism integrates directly with the flow engine's state machine, allowing activities to transition to a skipped state instead of failed or error when specific conditions are detected.

The underlying execution environment treats skipped activities as successfully completed for flow progression purposes while preserving the distinction in logs and reporting. When an activity is skipped, the flow engine continues to the next activity in sequence, passes any existing data pill values forward, and maintains the overall flow context without interruption. This differs fundamentally from error handling, which typically requires explicit catch blocks or error flows to prevent complete flow failure.

You cannot function without Skip Activity in scenarios where your flows process variable datasets and need to gracefully handle missing relationships. Employee onboarding flows that attempt to assign equipment based on role but skip the assignment when inventory is unavailable. Incident management flows that try to notify specific teams but continue processing when those teams don't exist for certain categories. Change management workflows that attempt to create deployment tasks but skip them when the target CI is decommissioned. Without Skip Activity, these flows would fail completely on edge cases that represent normal business variations rather than actual system errors.

Flow developers and automation architects primarily configure Skip Activity logic, while platform administrators manage the overall Flow Designer permissions and monitoring capabilities. Developers implement the conditional logic that determines when activities should skip versus error, typically using script conditions or action outputs to evaluate whether required data exists. Platform owners monitor flow execution patterns through Process Automation > Executions to identify when skip patterns indicate data quality issues or business process changes that need attention.

Starting with the Vancouver release, Skip Activity behavior was enhanced to provide better visibility in execution logs and improved integration with flow analytics. The Xanadu release introduced more granular skip conditions and better handling of data pill propagation through skipped activities, ensuring that downstream activities receive appropriate null or empty values rather than breaking data chains. These improvements made Skip Activity more predictable and easier to troubleshoot when building complex multi-step flows.

Where to Find and Configure It

Configure Skip Activity logic within individual flow activities by navigating to Process Automation > Flow Designer, opening your target flow, and accessing the activity properties panel where you set conditional logic or script conditions that evaluate whether the activity should execute or skip.

Access flow execution details and skip activity results through Process Automation > Executions where you can drill into individual flow runs to see which activities were skipped and why. View the underlying execution data in the sys_flow_context table using System Definition > Tables to analyze skip patterns across multiple executions. Monitor skip activity trends through Process Automation > Flow Analytics which provides aggregate reporting on flow execution states including skip frequencies.

In Studio environments, access flows through Studio > Create Application File > Flow for scoped applications, while global flows remain accessible through the standard Flow Designer interface. App Engine Studio provides the same skip activity configuration through its Logic and Automation > Flows section with a simplified interface for citizen developers. Both scoped and global applications handle Skip Activity identically, but scoped applications can only access and modify flows within their application scope unless specifically granted cross-scope access.

How It Works Step by Step

Skip Activity operates through conditional evaluation at the individual activity level within the flow execution pipeline. When a flow reaches an activity configured with skip conditions, the flow engine evaluates these conditions before attempting to execute the activity's main logic. If the skip condition returns true, the engine marks the activity as skipped, logs the skip reason, and immediately proceeds to the next activity without executing the intended operation.

The skip mechanism preserves data pill values and flow context while bypassing the activity's execution, ensuring that downstream activities can still reference previous outputs even when intermediate activities are skipped. This differs from error handling where the flow typically stops or diverts to error paths, and from conditional activities where the activity itself contains the conditional logic within its execution rather than having external skip criteria.

The Execution Order

1. Flow engine reaches the target activity and reads its skip condition configuration from the flow definition
2. Engine evaluates the skip condition using current flow context, data pills, and any referenced records or variables
3. If skip condition is false, activity executes normally; if true, engine marks activity state as 'skipped' in sys_flow_context
4. Engine logs the skip event with timestamp and reason in the execution history
5. Data pill values from previous activities remain available while skipped activity outputs return null or configured default values
6. Flow continues to next activity in sequence without error state or flow interruption

// Skip activity if target user's department doesn't exist
// Common pattern for user-related automation flows

var targetUser = fd_data.lookup('sys_user').get('user_id');
if (!targetUser || !targetUser.department.nil()) {
    return false; // Don't skip, user and department exist
}

// Check if department has specific attributes needed for this activity
var dept = targetUser.department.getRefRecord();
if (!dept.isValidRecord()) {
    fd_data.addInfoMessage('Skipping notification - user department not found');
    return true; // Skip this activity
}

// Additional validation for department-specific requirements
if (dept.getValue('cost_center') == '' || dept.getValue('manager') == '') {
    fd_data.addInfoMessage('Skipping activity - department missing required data');
    return true;
}

return false; // All conditions met, execute activity

Real-World Scenarios

Employee Equipment Assignment Flow

Your HR onboarding flow needs to automatically assign laptops and phones to new employees based on their role, but equipment inventory varies by location and availability. Rather than failing the entire onboarding process when specific equipment isn't available, you want to skip the assignment activity and continue with other onboarding tasks.

Configure the Create Equipment Request activity with a skip condition that queries the alm_asset table for available equipment matching the employee's role and location. Set the condition to Skip if no matching assets with install_status = 'In stock' AND location = employee.location. Add an Add to Data Stream action immediately after to log which equipment types were skipped for follow-up procurement.

Watch for role-based equipment requirements changing without updating your skip conditions, which can cause essential equipment to be skipped inappropriately. Monitor the equipment skip frequency through flow analytics to identify when procurement needs to adjust inventory levels. Ensure your skip condition accounts for equipment reserved for other pending hires by checking allocation tables, not just current stock status.

Incident Team Notification with Dynamic Assignments

Your incident management flow attempts to notify specialized support teams based on incident category and affected CI, but some categories don't have dedicated teams or teams are temporarily disbanded. You need the incident to continue processing through standard channels rather than failing when specific team notifications can't be sent.

Create a Send Team Notification activity with skip logic that queries sys_user_group for active groups matching the incident category. Configure the condition as Skip if group.active != true OR group.email is empty OR group.manager is empty. Add a parallel Update Incident Work Notes activity that only executes when team notification is skipped, documenting which specialized team couldn't be contacted.

Be careful with group membership validation timing since teams can be modified during incident processing, potentially causing race conditions in your skip logic. Set up monitoring for skipped team notifications to identify when incident categories consistently lack proper team assignments, indicating process gaps. Consider implementing fallback notification to incident managers when specialized teams are unavailable rather than just skipping the notification entirely.

Change Management Deployment Task Creation

Your change management workflow automatically creates deployment tasks for affected configuration items, but some CIs may be decommissioned, in maintenance, or temporarily unavailable during the change window. You want deployment planning to continue for available CIs while gracefully skipping unavailable ones without blocking the entire change process.

// Skip deployment task creation for unavailable CIs
// Check CI status and maintenance windows

var targetCI = fd_data.lookup('cmdb_ci').get('affected_ci');
if (!targetCI.isValidRecord()) {
    fd_data.addInfoMessage('Skipping deployment - CI not found');
    return true;
}

// Check CI operational status
var ciStatus = targetCI.getValue('operational_status');
if (ciStatus == 'Retired' || ciStatus == 'Decommissioned') {
    fd_data.addInfoMessage('CI ' + targetCI.getDisplayValue() + ' is decommissioned');
    return true;
}

// Check for active maintenance windows
var gr = new GlideRecord('maintenance_schedule');
gr.addQuery('cmdb_ci', targetCI.sys_id);
gr.addQuery('start_time', '<=', gs.nowDateTime());
gr.addQuery('end_time', '>=', gs.nowDateTime());
gr.query();
if (gr.next()) {
    fd_data.addInfoMessage('Skipping - CI in maintenance window until ' + gr.end_time);
    return true;
}

return false;

Monitor CI status changes that occur after skip evaluation but before change implementation, as CIs can transition states during long-running change processes. Implement proper error handling for CMDB relationship queries since CI relationships can be complex and circular references may cause your skip logic to fail unexpectedly. Consider adding business rule integration to automatically update change task status when skipped CIs become available again during the change window.

The Classic Mistake

The most common mistake is writing Skip Activity conditions that reference fields or properties without proper null checking. Admins often create conditions like fd_data.incident.state == '6' assuming the incident record always exists. When the record is null or the field doesn't exist, the condition throws a JavaScript error instead of evaluating to false. This defeats the entire purpose of Skip Activity because the flow stops with an error rather than gracefully skipping the problematic step.

// BAD - Will error if incident is null or doesn't have state field
fd_data.incident.state == '6' || fd_data.incident.state == '7'

// BAD - Assumes caller_id always exists and has a valid reference
fd_data.incident.caller_id.department.name == 'IT'

// BAD - No protection against undefined variables
fd_data.approval_count > 3 && fd_data.approval_status == 'approved'

// BAD - String methods on potentially null values
fd_data.incident.short_description.indexOf('urgent') > -1

// These conditions will throw errors instead of returning false,
// causing the flow to fail rather than skip the activity

When these conditions fail, users see generic flow execution errors in their notifications or UI actions don't complete properly. Internally, ServiceNow logs JavaScript evaluation errors in sys_flow_context records with state set to failed instead of skipped. The error is non-obvious because the condition syntax looks correct, but JavaScript's strict evaluation means any reference to undefined properties throws an exception before the comparison can return false. Flow designers expect the condition to fail gracefully, but JavaScript doesn't work that way without explicit protection.

// GOOD - Proper null checking prevents errors
fd_data.incident && (fd_data.incident.state == '6' || fd_data.incident.state == '7')

// GOOD - Chain existence checks for deep references
fd_data.incident && fd_data.incident.caller_id && 
fd_data.incident.caller_id.department && 
fd_data.incident.caller_id.department.name == 'IT'

// GOOD - Validate variables exist before using them
typeof fd_data.approval_count != 'undefined' && 
fd_data.approval_count > 3 && fd_data.approval_status == 'approved'

// GOOD - Check string exists before calling methods
fd_data.incident && fd_data.incident.short_description && 
fd_data.incident.short_description.indexOf('urgent') > -1

When to Use This vs Alternatives

Skip Activity is the right choice when you need flows to gracefully handle missing data or optional processing steps without breaking the entire automation chain. Use it when business processes have legitimate scenarios where certain steps shouldn't execute, but the overall flow must continue to completion.

When Skip Activity is the Correct Choice

Choose Skip Activity for integration flows where external systems might not have required data, approval processes where certain steps are conditional, or notification workflows where recipients might not exist. Conditional flow logic using If activities becomes unwieldy when you have multiple optional steps, and error handling with Try/Catch is overkill when missing data isn't actually an error condition. Skip Activity provides cleaner flow logic and better audit trails by explicitly marking steps as intentionally skipped rather than failed or bypassed.

When to Use Conditional Logic Instead

Use If activities when you need different execution paths based on business logic rather than data availability. If the decision is about which action to take rather than whether to skip an action entirely, conditional flow control is more appropriate. Skip Activity doesn't provide alternative execution paths, it only marks steps as not executed, so you can't use it to route flows to different outcomes based on business rules.

When to Combine Skip Activity with Error Handling

Use Skip Activity with Try/Catch blocks when some missing data should be skipped gracefully but actual system errors need proper error handling. Configure Skip Activity for expected data gaps and wrap the flow section in error handling for unexpected failures like network timeouts or permission errors. This combination ensures flows handle both business-level exceptions (skip) and system-level exceptions (error recovery) appropriately.

Platform Interactions & Side Effects

• Flow execution context records in sys_flow_context show skipped activities with state set to skipped instead of completed, creating distinct audit trails for troubleshooting
• Business Rules triggered by flow activities don't execute when activities are skipped, potentially missing important validation or calculation logic that downstream processes expect
• Update Set capture misses skipped activities during transport between instances, but captures the Skip Activity configuration itself in sys_hub_flow and sys_hub_step_config tables
• Notification activities that are skipped don't create records in sysevent_email_action or sys_email, making it difficult to track why expected communications didn't occur
• SLA task activities that are skipped don't pause or resume SLA calculations, potentially causing SLA breaches when expected pause triggers don't execute
• Performance Analytics widgets and KPIs don't count skipped activities as failures, but also don't count them as successful completions, affecting automation success metrics
• Flow variables and data pills from skipped activities retain their previous values rather than being cleared, which can cause unexpected data persistence in subsequent flow executions
• Access Control Lists don't apply to Skip Activity condition evaluation, so flows can skip activities based on data the running user couldn't normally read
• Integration Hub spokes track skipped activities differently in sys_hub_action_instance, showing execution_state as not_executed rather than success or failure
• Session state and user context remain unchanged during Skip Activity evaluation, but the skip condition executes in the flow's security context rather than the triggering user's context

Debugging and Troubleshooting

The most common failure symptom is flows that error out completely instead of skipping activities, usually manifesting as generic "Flow execution failed" messages in user notifications or incomplete business processes. Users report that expected automation didn't complete, but they don't see clear error messages explaining why. Administrators see flow execution records in sys_flow_context showing state as failed rather than the expected completed or skipped states.

Start troubleshooting by checking System Log > All for JavaScript evaluation errors during flow execution, filtering by source containing "flow" or "hub". Look for error messages like "Cannot read property of undefined" or "ReferenceError" which indicate Skip Activity conditions are trying to access non-existent data. The Flow Designer execution details show individual step outcomes, but you need to drill into the sys_flow_context record's result field to see the actual error details when skip conditions fail.

Pay attention to specific error patterns: "TypeError: Cannot read property 'state' of null" indicates missing record references, "ReferenceError: fd_data is not defined" suggests data pill configuration problems, and "Cannot read property of undefined" typically means accessing nested object properties without null checking. Enable the system property glide.flow.log_level set to "debug" to get more detailed flow execution logging, including skip condition evaluation results. The Flow Designer's test functionality doesn't always replicate production data conditions, so test skip scenarios with realistic data gaps to verify conditions work properly.

Diagnostic Checklist:

• Check sys_flow_context.result field for JavaScript errors in skip condition evaluation
• Verify all data pills referenced in skip conditions exist in the flow's data context using Flow Designer's data pill browser
• Test skip conditions with null or undefined values by temporarily creating flows with missing record lookups
• Review System Log entries during flow execution timeframes for "Cannot read property" or "ReferenceError" messages
• Validate that skip conditions use proper null checking syntax with && operators before property access
• Check flow version history to ensure Skip Activity configuration wasn't accidentally modified during recent flow updates
• Examine the flow's trigger data to confirm expected variables are actually available when skip conditions evaluate

Quick Reference

• Skip Activity conditions execute in the flow's security context with elevated privileges, not the triggering user's permissions
• Skipped activities don't clear their output variables - previous execution values persist and can cause data pollution in subsequent flow runs
• Maximum skip condition length is 4000 characters, stored in sys_hub_step_config.value field with configuration key "skip_condition"
• Flow Designer test runs don't accurately simulate skip conditions with missing data - always test with real production-like scenarios
• Skip Activity evaluation adds approximately 50-100ms to flow execution time due to condition parsing and JavaScript evaluation overhead
• Subflow activities that are skipped don't execute any of their internal steps, but the subflow's completion outputs still become available to the parent flow
• Clone operations don't preserve Skip Activity configurations - they must be manually reconfigured after cloning flows between instances
• Activities with Skip Activity enabled show a small "S" indicator in Flow Designer's visual editor when the condition is configured
• Skip conditions can reference data from activities that haven't executed yet, but this causes evaluation errors - always reference only upstream activity outputs
• Integration Hub Action activities respect Skip Activity settings but still count against spoke execution limits even when skipped