sys_hub_subflow Table

Table Reference/sys_hub_subflow

The sys_hub_subflow table stores reusable Flow Designer subflows that can be called from flows or other subflows. Owned by the Flow Designer module, this table enables component reusability across automation workflows. The most important thing to know: always check the `active` field and `category` when querying, as inactive subflows won't execute even if referenced.

What This Table Is

The sys_hub_subflow table stores reusable Flow Designer subflows—modular workflow components that encapsulate common automation logic. These subflows act as functions in Flow Designer, accepting inputs and returning outputs while hiding implementation complexity from consuming flows.

Owned by the Flow Designer module, this table supports the entire Flow Designer automation ecosystem. Subflows enable developers to create reusable components that can be called from any flow or other subflow, promoting consistency and reducing duplication across automation workflows.

This table extends sys_hub_flow and inherits core flow properties while adding subflow-specific functionality like input/output parameter definitions. No tables extend sys_hub_subflow directly—it's the leaf table in this inheritance hierarchy.

Record volume is typically moderate in enterprise instances—hundreds to low thousands of subflows. Performance is generally good since these records are primarily read during flow execution setup, not during high-volume transaction processing. However, querying by category can be expensive without proper indexing on large datasets.

When You'll Script Against This Table

You'll primarily script against sys_hub_subflow in Script Includes when building Flow Designer management tools, Business Rules for subflow lifecycle management, and Scheduled Jobs for subflow maintenance. REST API integrations often query this table to discover available subflows or validate subflow references.

Access requires flow_designer role for full CRUD operations. The flow_operator role provides read access for execution contexts. Application scope affects visibility—global subflows are visible to all scopes, while scoped subflows are only accessible within their scope unless explicitly shared.

Query subflows by category for dynamic flow building
Validate subflow existence before creating flow references
Count subflows by scope for governance reporting
Bulk activate/deactivate subflows during deployment
Extract input/output definitions for documentation generation
Monitor subflow usage patterns across flows
Synchronize subflow versions between instances

Table Gotchas

⚠️

Inactive subflows (active=false) will cause flows that reference them to fail at runtime, but Flow Designer won't validate this at design time. Always verify subflow status before deployment.

The category field is a string, not a choice field, so typos create new categories rather than validation errors

⚠️

The sys_scope field determines subflow visibility across applications. Cross-scope subflow calls require explicit sharing or will fail silently in some execution contexts.

Subflow versioning is handled through copied_from relationships, not traditional version fields—query the reference chain for version history
The inputs and outputs fields contain JSON that must be parsed—direct string queries against these fields are unreliable

⚠️

Deleting subflows doesn't automatically remove references from flows that use them. This creates broken references that cause runtime failures.

Performance suffers when querying by description or other long text fields without proper indexing—use name or category for better query performance

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_subflow table extends sys_hub_flow, inheriting core flow functionality like activation status, scope, and basic metadata. When querying subflows, you often need to join with the parent table to access shared flow properties.

The most common related tables are sys_hub_flow_step for subflow references within flows, sys_scope for application context, and sys_hub_action_input/sys_hub_action_output for input and output parameter definitions. You'll frequently join these tables when building subflow management tools or analyzing subflow usage patterns across your Flow Designer ecosystem.

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	The subflow's display name. Must be unique within the scope and is used for subflow selection in Flow Designer.
active	boolean	Active	Controls subflow availability for execution. Inactive subflows cause runtime failures in flows that reference them.
category	string	Category	Groups subflows for organization. This is a free-text field, not a choice list, so typos create new categories.
description	string	Description	Long text description of subflow functionality. Avoid querying this field directly due to performance implications.
sys_scope	reference	Application	References sys_scope table. Determines subflow visibility across applications and affects cross-scope subflow calls.
copied_from	reference	Copied from	Self-reference for subflow versioning. Links to the original subflow when creating copies, forming a version chain.
inputs	json	Inputs	JSON definition of input parameters. Contains parameter names, types, and constraints for subflow execution.
outputs	json	Outputs	JSON definition of output parameters. Defines what data the subflow returns to calling flows or subflows.
flow_designer_type	string	Flow Designer Type	Always 'subflow' for this table. Inherited from parent sys_hub_flow table to distinguish from regular flows.
template	reference	Template	References template definition if subflow was created from a template. Null for custom-built subflows.
protect_inputs	boolean	Protect Inputs	When true, prevents modification of input parameter values in flows that use this subflow.
run_as	choice	Run As	Execution context: 'user' (calling user's context) or 'system' (elevated system context). Affects permissions during execution.
published_version	string	Published Version	Version identifier for published subflows. Used to track subflow versions across instances and deployments.
api_name	string	API Name	Unique identifier for REST API access. Generated automatically but can be customized for better API integration.
internal	boolean	Internal	Marks system-created subflows. Internal subflows may have different upgrade behavior and visibility restrictions.

Common Queries

Get all active subflows

// Most basic query - active subflows available for use
var gr = new GlideRecord('sys_hub_subflow');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    gs.info('Active subflow: ' + gr.getValue('name') + 
            ' (' + gr.getValue('category') + ')');
}

Find subflows by category and scope

// Filter by category and application scope
var gr = new GlideRecord('sys_hub_subflow');
gr.addQuery('active', true);
gr.addQuery('category', 'ITSM');
// Query by scope name instead of sys_id for readability
gr.addQuery('sys_scope.name', 'Service Management');
gr.query();

while (gr.next()) {
    gs.info('ITSM subflow: ' + gr.getValue('name') + 
            ' in scope: ' + gr.getDisplayValue('sys_scope'));
}

Get subflows with input parameters for validation

// Real-world scenario: validate subflows have required inputs
var gr = new GlideRecord('sys_hub_subflow');
gr.addQuery('active', true);
gr.addNotNullQuery('inputs');
gr.query();

while (gr.next()) {
    var inputs = JSON.parse(gr.getValue('inputs') || '[]');
    var hasRequiredInputs = inputs.some(function(input) {
        return input.mandatory === true;
    });
    
    if (hasRequiredInputs) {
        gs.info('Subflow with required inputs: ' + gr.getValue('name'));
    }
}

Count subflows by category using GlideAggregate

// Aggregate count for governance reporting
var agg = new GlideAggregate('sys_hub_subflow');
agg.addQuery('active', true);
agg.groupBy('category');
agg.addAggregate('COUNT');
agg.query();

while (agg.next()) {
    var category = agg.getValue('category') || 'Uncategorized';
    var count = agg.getAggregate('COUNT');
    gs.info('Category: ' + category + ', Count: ' + count);
}

Gotcha: Wrong way vs right way to check subflow existence

// WRONG: This misses inactive subflows that might be referenced
// var gr = new GlideRecord('sys_hub_subflow');
// gr.addQuery('name', 'My Subflow');
// gr.addQuery('active', true);

// RIGHT: Check existence first, then verify status separately
var gr = new GlideRecord('sys_hub_subflow');
gr.addQuery('name', 'My Subflow');
if (gr.query() && gr.next()) {
    if (!gr.getValue('active')) {
        gs.warn('Subflow exists but is inactive: ' + gr.getValue('name'));
    }
    // Proceed with subflow logic
}

Related Tables

sys_hub_flow

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