sys_hub_flow Table — ServiceNow Reference

Table Reference/sys_hub_flow

The `sys_hub_flow` table stores Flow Designer flows in the Flow Designer module. Each record represents a complete flow definition with its trigger configuration, active state, and internal JSON graph structure. While not designed for direct scripting manipulation, it's essential for flow inventory, reporting, and administrative queries.

What This Table Is

The sys_hub_flow table stores Flow Designer flow definitions — the complete configuration of each flow including its trigger, actions, data processing logic, and execution flow. Each record represents a single flow that can be activated, deactivated, and executed by the Flow Engine. The table contains both metadata about the flow (name, description, trigger type) and the complete internal representation as a JSON graph structure.

Flow Designer owns this table as the primary storage mechanism for all flows created through the visual flow designer interface. The table supports the complete flow lifecycle from design-time creation and testing through runtime execution and monitoring. Flows stored here can be triggered by record operations, scheduled intervals, REST API calls, or manual execution depending on their trigger_type configuration.

This table does not extend any parent table — it's a standalone entity designed specifically for Flow Designer. No tables extend sys_hub_flow either, though related execution and logging tables reference flows by their sys_id. The table has strong relationships with sys_hub_flow_instance for execution tracking and sys_hub_action_instance for individual step execution records.

Enterprise instances typically contain hundreds to low thousands of flow records, making this a relatively small table with excellent query performance. However, the graph field can contain substantial JSON payloads for complex flows, so avoid querying it unnecessarily in loops or when only metadata is needed.

When You'll Script Against This Table

Most scripting against sys_hub_flow happens in Script Includes for administrative functions, Scheduled Jobs for flow maintenance, and Business Rules that need to programmatically activate or deactivate flows based on business conditions. The Flow Designer scope (sn_fd) provides the primary APIs for interacting with flows, but direct table access is sometimes necessary for bulk operations or reporting.

The table requires flow_designer role for full access, though flow_operator can read most fields. ACLs prevent modification of active flows in production scopes without proper permissions. The graph field is particularly protected as it contains the complete flow definition.

Common scripting patterns:

Flow inventory and audit reports — counting active flows by trigger type or application scope
Bulk activation/deactivation of flows during maintenance windows or deployment processes
Environment-specific flow management — disabling flows that shouldn't run in non-production
Application scoped flow discovery for Update Set management and scoped app packaging
Flow dependency analysis by parsing trigger conditions and referenced tables
Performance monitoring by joining with execution instance tables to identify problematic flows
Custom flow validation rules that check flow configurations against organizational standards

Table Gotchas

⚠️

Never directly modify the `graph` field — it contains the complete flow definition as a complex JSON structure. Any changes should go through the Flow Designer interface or official APIs. Direct modifications will corrupt the flow and prevent execution.

⚠️

The `active` field doesn't immediately stop running flow instances. Setting a flow to inactive prevents new executions but doesn't cancel in-progress instances. Use the Flow Designer interface for proper flow lifecycle management.

The trigger_type field uses internal identifiers like 'record.inserted' rather than display values — always query by exact internal values, not what you see in the UI
Flow names (name field) are not unique across scopes — always include sys_scope in queries when flow names might be duplicated
The sys_package field points to the update set when the flow was created, not the current update set — use sys_scope for application scoping queries

⚠️

Querying the `graph` field on large result sets can cause significant performance issues. The JSON payload can be 50KB+ per flow. Always exclude it with `addNullQuery()` or `addNotNullQuery()` conditions unless you specifically need the graph data.

Flow execution permissions are evaluated at runtime based on the flow's scope and the triggering context — a flow might exist in the table but fail to execute due to ACL restrictions
The copied_from field creates a reference chain that can be several levels deep — flows copied from copied flows maintain the original reference, not the immediate parent

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 sys_hub_flow_instance table is the primary companion to sys_hub_flow, storing execution records for every time a flow runs. Each flow instance references the flow definition via the flow field, creating the foundation for flow execution monitoring and troubleshooting. The sys_hub_action_instance table stores individual step executions within each flow instance, providing detailed execution logs and error tracking.

Application scoping relationships connect flows to the sys_scope and sys_package tables for proper application lifecycle management. For record-triggered flows, the trigger configuration implicitly connects to various business tables like incident, change_request, sys_user, or any other table specified in the trigger conditions.

Flow scheduling integrates with the sysauto_script table for scheduled flows, while REST-triggered flows connect to the sys_rest_message infrastructure. Developers frequently join flow execution data with sys_user and sys_user_group to understand flow execution patterns and user impacts across the business process automation landscape.

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
name	string	Name	Flow display name shown in Flow Designer. Not unique across scopes — multiple flows can have the same name in different applications.
active	boolean	Active	Controls whether the flow can execute. Setting to false prevents new executions but doesn't stop running instances.
trigger_type	string	Trigger Type	Internal identifier for trigger mechanism like 'record.inserted', 'schedule', 'application.operation'. Use exact internal values in queries, not UI display names.
graph	string	Graph	Complete flow definition as JSON. Can be 50KB+ per record. Avoid querying unless specifically needed due to performance impact.
description	string	Description	User-provided flow description. Often empty despite being visible in the UI — check for null/empty values in queries.
sys_scope	reference	Application	Reference to sys_scope table. Use this for application-based queries, not sys_package which points to the update set when created.
copied_from	reference	Copied from	Reference to original flow when this is a copy. Chain can be multiple levels deep — references the ultimate source, not immediate parent.
run_as	reference	Run As	sys_user reference defining execution context. Empty means run as triggering user. Critical for understanding flow permissions and access.
category	string	Category	Optional categorization field. Often null but useful for organizing flows in large environments when populated.
template	boolean	Template	Marks flows designed as templates for copying. Template flows are typically inactive but contain reusable patterns.
condition	string	Condition	Encoded condition string for record-triggered flows. Contains table and field filter logic — not human-readable but essential for dependency analysis.
schedule	string	Schedule	Schedule configuration for scheduled flows. Contains repeat interval and timing data in internal format.
application_operation	string	Application Operation	Operation identifier for application-triggered flows. Links to specific ServiceNow operations that can invoke the flow.
latest_instance	reference	Latest Instance	Reference to most recent execution in sys_hub_flow_instance. Auto-maintained but can be null for never-executed flows.
flow_level	choice	Flow Level	Execution priority level. Higher levels get processing preference but require additional licensing in some environments.

Common Queries

Get all active flows

var gr = new GlideRecord('sys_hub_flow');
gr.addQuery('active', true);
// Exclude the large JSON graph field for performance
gr.addNullQuery('graph');
gr.query();

while (gr.next()) {
    gs.info('Active flow: ' + gr.name + ' (' + gr.trigger_type + ')');
}

Find flows by trigger type in specific application scope

var gr = new GlideRecord('sys_hub_flow');
gr.addQuery('trigger_type', 'record.inserted');
gr.addQuery('sys_scope.name', 'My Application');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    gs.info('Record trigger flow: ' + gr.name + ' in ' + gr.sys_scope.name);
    // Access trigger conditions to understand which tables
    if (gr.condition) {
        gs.info('Condition: ' + gr.condition);
    }
}

Find flows that might conflict with new business rules on incident table

var gr = new GlideRecord('sys_hub_flow');
gr.addQuery('trigger_type', 'STARTSWITH', 'record.');
gr.addQuery('active', true);
// Look for flows with incident table conditions
gr.addQuery('condition', 'CONTAINS', 'incident');
gr.query();

while (gr.next()) {
    gs.info('Potential incident flow conflict: ' + gr.name);
    gs.info('Last executed: ' + gr.latest_instance.sys_created_on);
    gs.info('Runs as: ' + gr.run_as.getDisplayValue());
}

Count flows by trigger type across all applications

var ga = new GlideAggregate('sys_hub_flow');
ga.addQuery('active', true);
ga.addAggregate('COUNT');
ga.groupBy('trigger_type');
ga.groupBy('sys_scope.name');
ga.query();

while (ga.next()) {
    var count = ga.getAggregate('COUNT');
    var triggerType = ga.getValue('trigger_type');
    var scope = ga.getDisplayValue('sys_scope.name');
    gs.info(scope + ': ' + count + ' flows with trigger ' + triggerType);
}

Wrong vs right way to check if flow ran recently

// WRONG: Expensive join that loads graph data
// var gr = new GlideRecord('sys_hub_flow');
// gr.addJoinQuery('sys_hub_flow_instance', 'sys_id', 'flow');

// RIGHT: Query instances first, then get flow details
var instanceGR = new GlideRecord('sys_hub_flow_instance');
instanceGR.addQuery('sys_created_on', '>', gs.daysAgoStart(1));
instanceGR.query();

while (instanceGR.next()) {
    var flowName = instanceGR.flow.name; // Automatic dot-walk
    gs.info('Recently executed: ' + flowName + ' at ' + instanceGR.sys_created_on);
}

Related Tables

sys_user sysauto_script

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