wf_context Table — ServiceNow Reference

Table Reference/wf_context

The wf_context table tracks active workflow execution instances in ServiceNow's Workflow module. Each record represents a running workflow with its current state, activity position, and execution context. The critical thing to know: workflows only create context records when they actually execute—draft workflows won't appear here.

What This Table Is

The wf_context table stores runtime execution instances of ServiceNow workflows. Each record represents an active workflow execution—tracking where the workflow is in its flow, what data it's operating on, and any errors that occurred during processing. This is the runtime state table that lets you debug why workflows get stuck, monitor execution progress, and understand what data workflows are working with.

The Workflow module owns this table and uses it to orchestrate all workflow execution. When a workflow starts—whether triggered by a business rule, scheduled job, or manual execution—ServiceNow creates a wf_context record to track that execution instance. The workflow engine continuously updates this record as activities complete, variables change, and the workflow progresses through its defined flow.

This table doesn't extend any parent table—it's a standalone system table. The related wf_context_log table captures the execution history and activity transitions for each context record, providing a detailed audit trail of workflow execution.

In large enterprises, this table can contain thousands of records during peak processing hours, especially with automated workflows processing incident assignments, approvals, and integrations. Records typically clean themselves up when workflows complete, but stuck workflows will leave context records active indefinitely. Performance is generally good since most queries filter by workflow or table fields, which are indexed.

When You'll Script Against This Table

Most developers query wf_context from Script Includes when building workflow monitoring tools, Background Scripts for debugging stuck workflows, and Business Rules that need to check if workflows are currently running against specific records. You'll also hit this table in Scheduled Jobs that clean up orphaned workflow contexts or send alerts about long-running workflows.

Access requires the workflow_admin role for full read/write access, though admin can also access these records. The workflow engine itself runs in elevated context, but custom scripts need proper permissions to query or modify workflow contexts.

Debug stuck workflows by finding contexts in waiting or error states
Monitor workflow execution progress by checking current activity positions
Prevent duplicate workflow execution by checking for existing active contexts
Extract workflow variable values from the serialized scratchpad data
Build workflow performance analytics by analyzing execution duration
Cancel or restart workflows programmatically by updating state values
Create workflow monitoring dashboards showing active execution counts by workflow type

Table Gotchas

⚠️

The scratchpad field stores workflow variables as XML, not JSON. Don't try to parse it with JSON methods—you'll need to use the Workflow API or parse the XML structure manually.

⚠️

State values are stored as integers, not strings. Use state != 3 instead of state != 'Finished' when querying for active workflows.

The document_id field stores the sys_id of the record the workflow is operating on, but it's a string field, not a reference—you can't dot-walk from it
Workflows can have multiple active contexts if they're designed with parallel flows—don't assume one workflow per record
The started timestamp uses the system timezone, not user timezone—factor this in for time-based queries

⚠️

Never update wf_context records directly unless you know what you're doing. The workflow engine expects specific state transitions—incorrect updates can corrupt workflow execution.

Performance trap: querying by document_id without filtering by table can be slow on large instances

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The wf_workflow table contains the workflow definitions that these contexts execute against. The workflow field in wf_context references this table to identify which workflow definition is being executed. You'll often join these tables to get workflow names, descriptions, and configuration details.

The wf_context_log table provides detailed execution history for each workflow context, showing activity transitions, timing, and error details. The wf_activity table defines the individual activities that make up workflows, and contexts reference current activities through the current_activity field.

Since workflows operate on various record types, you'll frequently join wf_context with business tables like incident, change_request, or sc_req_item using the document_id field to understand what records have active workflows and their current processing state.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
workflow	reference	Workflow	References wf_workflow table containing the workflow definition. This tells you which workflow is executing, but you'll need to dot-walk to get the workflow name.
state	integer	State	Workflow execution state as integer: 1=Executing, 2=Waiting, 3=Finished, 4=Cancelled, 7=Error. Most debugging queries filter for != 3 to find active workflows.
document_id	string	Document ID	The sys_id of the record this workflow is operating on. It's a string field, not a reference, so you can't dot-walk but must do separate queries to get record details.
table	string	Table	The table name (like 'incident' or 'change_request') that contains the record being processed. Essential for performance when querying by document_id.
current_activity	reference	Current Activity	References wf_activity table showing which workflow activity is currently executing. Null when workflow is starting up or finishing.
started	glide_date_time	Started	When this workflow execution began. Uses system timezone, not user timezone—important for time-based analysis and SLA calculations.
ended	glide_date_time	Ended	When workflow execution completed (finished, cancelled, or errored). Null for active workflows—use this to calculate execution duration.
scratchpad	string	Scratchpad	XML-serialized workflow variables and context data. Don't parse as JSON—use Workflow API methods or XML parsing to extract variable values.
fault_description	string	Fault Description	Error message when workflow execution fails. Only populated when state=7 (Error). Contains the actual JavaScript error or timeout message.
business_key	string	Business Key	Optional identifier for grouping related workflow executions. Workflows can set this to track multi-step processes or batch operations.
phase	integer	Phase	Internal workflow engine state tracking execution phase. Used by the engine for flow control—not typically useful for custom scripting.
stage	string	Stage	Current execution stage within the workflow engine. Values like 'begin', 'activity', 'end' track where the engine is in processing this context.
activity_index	integer	Activity Index	Position counter for the current activity in the workflow sequence. Useful for understanding how far through the workflow execution has progressed.
workflow_version	reference	Workflow Version	References wf_workflow_version for the specific workflow version being executed. Important when workflows are updated but existing contexts continue on old versions.
started_by	reference	Started By	References sys_user who initiated the workflow execution. May be system user for automated triggers or the actual user for manual workflow starts.

Common Queries

Get all currently active workflow contexts

// Find workflows that are still executing, waiting, or in error state
var gr = new GlideRecord('wf_context');
gr.addQuery('state', '!=', 3); // Not finished
gr.orderByDesc('started');
gr.query();

while (gr.next()) {
    gs.print(gr.workflow.name + ' on ' + gr.table + ': ' + gr.getValue('state'));
}

Find stuck workflows in error state for a specific table

// Debug workflows that failed on incident records
var gr = new GlideRecord('wf_context');
gr.addQuery('state', 7); // Error state
gr.addQuery('table', 'incident');
gr.query();

while (gr.next()) {
    gs.print('Failed workflow: ' + gr.workflow.name);
    gs.print('Document: ' + gr.document_id);
    gs.print('Error: ' + gr.fault_description);
    gs.print('---');
}

Check if workflows are currently running against a specific record

// Prevent duplicate workflow execution by checking for active contexts
var recordId = 'abc123'; // sys_id of record to check
var recordTable = 'incident';

var gr = new GlideRecord('wf_context');
gr.addQuery('document_id', recordId);
gr.addQuery('table', recordTable);
gr.addQuery('state', '!=', 3); // Not finished
gr.query();

if (gr.hasNext()) {
    gs.print('Active workflows found - skipping duplicate execution');
} else {
    gs.print('No active workflows - safe to start new workflow');
}

Count active workflow contexts by workflow type

// Get execution statistics for monitoring dashboard
var ga = new GlideAggregate('wf_context');
ga.addQuery('state', '!=', 3); // Active workflows only
ga.groupBy('workflow');
ga.addAggregate('COUNT');
ga.query();

while (ga.next()) {
    var workflowGr = new GlideRecord('wf_workflow');
    workflowGr.get(ga.getValue('workflow'));
    gs.print(workflowGr.name + ': ' + ga.getAggregate('COUNT') + ' active');
}

Wrong vs right way to query workflow contexts by duration

// WRONG: This will scan all records and calculate duration client-side
// var gr = new GlideRecord('wf_context');
// gr.query();
// Filter long-running workflows in loop - SLOW!

// RIGHT: Use server-side date comparison for performance
var gr = new GlideRecord('wf_context');
gr.addQuery('state', '!=', 3); // Active only
gr.addQuery('started', '<', gs.daysAgo(1)); // Started over 1 day ago
gr.orderBy('started'); // Oldest first
gr.query();

// Now you have only long-running workflows, filtered efficiently on server

Related Tables

wf_workflow incident change_request

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue