sys_hub_action_type_base Table

Table Reference/sys_hub_action_type_base

The `sys_hub_action_type_base` table stores Flow Designer action definitions — both custom and out-of-box reusable actions that flows can execute. Owned by Flow Designer, the key thing to know is that records here define action metadata and interface, not execution instances.

What This Table Is

The sys_hub_action_type_base table stores the master catalog of Flow Designer actions — reusable components that flows can execute to perform specific tasks. Each record defines an action's interface, inputs, outputs, and execution logic. This includes both ServiceNow's out-of-box actions (Create Record, Send Email, Wait for Condition) and custom actions built by developers.

This table belongs to Flow Designer and serves as the foundation for the entire action ecosystem. When you drag an action into a flow, Flow Designer reads this table to determine what inputs the action needs, what outputs it provides, and how to execute it. The table supports Flow Designer's visual interface by storing action categories, descriptions, and UI hints that appear in the action picker.

The table extends sys_metadata and has several child tables including sys_hub_action_type_script for script actions and sys_hub_action_type_subflow for subflow actions. Each child table stores type-specific configuration while inheriting the base action definition structure. Action instances (actual executions within flows) are stored separately in sys_hub_action_instance.

In a large enterprise, expect 200-500 action records — mostly out-of-box actions with 50-100 custom actions. Performance is generally good since this table is read-heavy (actions are defined once, executed many times) and relatively small. However, complex action input/output definitions stored in JSON fields can impact query performance when filtering on action capabilities.

When You'll Script Against This Table

You'll primarily script against this table in Flow Designer administrative contexts — building custom action pickers, validating action configurations, or creating dynamic flow builders. Most commonly in Script Includes that support Flow Designer UI components, Business Rules that govern action publishing, and background scripts for action migration or cleanup. Less commonly in client scripts for custom Flow Designer interfaces.

Access requires the flow_designer role for most operations. Custom action creation requires action_designer. Records are scoped, so cross-scope action access follows standard application scoping rules. Published actions become available globally, while draft actions remain scope-restricted.

Common scripting patterns:

Query published actions by category to build custom action catalogs
Validate action input/output schemas before flow execution
Find actions that reference specific tables or fields for impact analysis
Bulk update action metadata during upgrades or organizational changes
Generate action usage reports by cross-referencing with flow instances
Programmatically create or clone custom actions with standardized patterns
Synchronize action definitions across instances during deployment

Table Gotchas

⚠️

The `state` field uses non-obvious values: 'published' for active actions, 'draft' for development, 'retired' for deprecated. Don't assume 'active' exists.

The inputs and outputs fields contain complex JSON schemas that require parsing, not simple string matching

⚠️

Action types have inheritance chains. A script action record exists in both this base table AND `sys_hub_action_type_script`. Query the specific child table for type-specific fields.

The sys_package reference determines action scope and upgrade behavior — custom actions without proper package assignment can disappear during upgrades
Performance trap: avoid CONTAINS queries on JSON fields — use specific field matches or GlideRecord with JavaScript filtering instead

⚠️

The `annotation` field stores action descriptions and help text in XML format, not plain text. Parse it properly or use the Flow Designer APIs instead of direct field access.

Action versioning is implicit through the update process — there's no version field, so track changes through sys_updated_on and audit records

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.

This table extends sys_metadata, inheriting standard metadata fields like sys_package, sys_scope, and sys_policy. The child tables sys_hub_action_type_script and sys_hub_action_type_subflow store action-type-specific configuration while pointing back to base action definitions here.

You'll frequently join with sys_hub_action_instance to find where actions are used in flows, and sys_hub_flow_context to understand execution contexts. The sys_hub_category table provides action categorization for the Flow Designer interface. When building comprehensive flow analysis, you'll often query sys_hub_flow alongside this table to understand which flows can execute which actions.

For action execution analysis, sys_execution_tracker records provide runtime performance data linked back to action definitions. The sys_log table captures action execution errors and debug information, making the combination essential for troubleshooting custom actions in production environments.

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	Internal action name used in flow references. Must be unique within scope and cannot contain spaces or special characters.
label	string	Label	Display name shown in Flow Designer action picker. Can contain spaces and special characters unlike the name field.
state	choice	State	Action lifecycle state: 'published' (available for use), 'draft' (under development), 'retired' (deprecated but not deleted).
type	choice	Type	Action implementation type: 'script', 'subflow', 'rest', etc. Determines which child table contains additional configuration.
category	reference	Category	References sys_hub_category for Flow Designer organization. Affects where the action appears in the action picker tree.
inputs	json	Inputs	JSON schema defining action input parameters. Used by Flow Designer to generate input forms and validate data types.
outputs	json	Outputs	JSON schema defining action output values. Flow Designer uses this to provide data pills for subsequent flow steps.
annotation	xml	Annotation	Action description and help text in XML format. Contains rich text formatting and tooltips shown in Flow Designer.
sys_scope	reference	Application	Scoped application that owns this action. Determines visibility and upgrade behavior across application boundaries.
sys_package	reference	Package	Update set package for deployment. Critical for custom actions — missing package can cause actions to disappear during upgrades.
active	boolean	Active	Administrative override for action availability. Even published actions won't appear in picker if inactive.
latest	boolean	Latest	Indicates if this is the current version of the action. ServiceNow uses this internally for action evolution.
copyable	boolean	Copyable	Whether users can create copies of this action as starting points for custom actions. Typically true for templates.
deletable	boolean	Deletable	Whether this action can be deleted from the system. ServiceNow out-of-box actions are typically not deletable.
access	choice	Access	Access level for action usage: 'public' (all scopes), 'restricted' (same scope only). Affects cross-scope flow development.
sys_class_name	string	Class Name	Table name for polymorphic queries. Always 'sys_hub_action_type_base' for base records, child table names for specific types.

Common Queries

Get all published actions available for use

// Most basic query - what developers try first
var gr = new GlideRecord('sys_hub_action_type_base');
gr.addQuery('state', 'published');
gr.addQuery('active', true);
gr.orderBy('label');
gr.query();

while (gr.next()) {
    gs.print(gr.getValue('label') + ' (' + gr.getValue('name') + ')');
    gs.print('Category: ' + gr.category.getDisplayValue());
    gs.print('Type: ' + gr.getValue('type'));
    gs.print('---');
}

Find script actions in a specific category by scope

// Filter by state, type, and scope reference
var gr = new GlideRecord('sys_hub_action_type_base');
gr.addQuery('state', 'published');
gr.addQuery('type', 'script');
gr.addQuery('sys_scope.name', 'Global'); // or specific app scope
gr.addQuery('category.name', 'ServiceNow Core'); // specific category
gr.query();

while (gr.next()) {
    gs.print('Script Action: ' + gr.getValue('label'));
    gs.print('Scope: ' + gr.sys_scope.getDisplayValue());
    gs.print('Package: ' + gr.sys_package.getDisplayValue());
}

Find custom actions that might need migration review

// Real-world scenario - audit custom actions before upgrade
var gr = new GlideRecord('sys_hub_action_type_base');
gr.addQuery('sys_created_by', '!=', 'system');
gr.addQuery('sys_scope.scope', '!=', 'global'); // not global scope
gr.addQuery('sys_package', ''); // no package assigned
gr.addQuery('active', true);
gr.orderBy('sys_created_on');
gr.query();

gs.print('Custom actions without packages (upgrade risk):');
while (gr.next()) {
    gs.print(gr.getValue('name') + ' - Created: ' + gr.getValue('sys_created_on'));
    gs.print('Scope: ' + gr.sys_scope.getDisplayValue());
    gs.print('Creator: ' + gr.getValue('sys_created_by'));
}

Count actions by category and type using GlideAggregate

// Aggregate count for action inventory reporting
var ga = new GlideAggregate('sys_hub_action_type_base');
ga.addQuery('active', true);
ga.addAggregate('COUNT');
ga.groupBy('category');
ga.groupBy('type');
ga.query();

gs.print('Action counts by category and type:');
while (ga.next()) {
    var category = ga.category.getDisplayValue() || 'No Category';
    var type = ga.getValue('type') || 'Unknown';
    var count = ga.getAggregate('COUNT');
    gs.print(category + ' - ' + type + ': ' + count);
}

Wrong way vs right way to search action inputs/outputs

// WRONG: This will be slow and unreliable
// var gr = new GlideRecord('sys_hub_action_type_base');
// gr.addQuery('inputs', 'CONTAINS', 'table_name');

// RIGHT: Get records first, then parse JSON in JavaScript
var gr = new GlideRecord('sys_hub_action_type_base');
gr.addQuery('state', 'published');
gr.addQuery('inputs', '!=', '');
gr.query();

// Parse JSON to find specific input schema elements
while (gr.next()) {
    try {
        var inputs = JSON.parse(gr.getValue('inputs') || '[]');
        // Check if any input references 'incident' table
        if (inputs.some(input => input.schema && input.schema.table === 'incident')) {
            gs.print('Action uses incident table: ' + gr.getValue('name'));
        }
    } catch (e) {
        // Handle malformed JSON gracefully
        gs.print('Invalid input JSON in action: ' + gr.getValue('name'));
    }
}

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