sys_ui_action Table — ServiceNow Reference

Table Reference/sys_ui_action

The sys_ui_action table stores form buttons, related links, and context menu items across ServiceNow. Owned by the Development module, these records define both UI elements and their associated client-side or server-side scripts. Critical gotcha: UI Actions with client scripts execute before the form submits, while server-side actions run after form submission.

What This Table Is

The sys_ui_action table stores UI Action records that define form buttons, related links, and context menu items throughout the ServiceNow platform. Each record specifies where the action appears, what conditions control its visibility, and what script executes when users interact with it. UI Actions are the primary mechanism for adding custom functionality to forms, lists, and context menus.

Owned by the Development module, UI Actions support the entire custom application development process. They enable developers to extend standard ServiceNow forms with business-specific functionality, integrate with external systems, and provide shortcuts for common operations. UI Actions can execute client-side JavaScript for immediate user feedback or server-side scripts for data manipulation and business logic.

The sys_ui_action table is a standalone table that doesn't extend other tables. However, it has strong relationships with sys_db_object (through the table field) and sys_ui_view (through the view field). UI Actions can be global or table-specific, appearing on forms, lists, or both depending on configuration.

Large enterprises typically have 500-2000 UI Action records, with the majority being out-of-box platform actions. Custom UI Actions rarely cause performance issues since they're loaded on-demand per form or list. However, complex condition scripts or poorly written client-side code can impact form load times and user experience.

When You'll Script Against This Table

Developers primarily interact with this table through Script Includes when dynamically creating or modifying UI Actions, Business Rules when reacting to UI Action changes, and scheduled jobs when performing bulk updates to action configurations. Client Scripts occasionally query UI Actions to determine which buttons are available, though direct DOM manipulation is often preferred for client-side button management.

Access to sys_ui_action requires the admin role or a custom role with access to the Application Development scope. UI Actions themselves respect ACLs and role requirements defined in their configuration, but the underlying table requires elevated permissions to modify programmatically.

Creating dynamic form buttons based on record state or user roles
Disabling or hiding actions based on business rules or approval states
Bulk updating action visibility across multiple tables during application deployment
Querying which actions are available for audit or compliance reporting
Creating approval workflow buttons that appear only at specific workflow stages
Implementing table-specific integrations that require custom form buttons
Migrating UI Actions between instances while preserving dependencies and conditions

Table Gotchas

⚠️

UI Actions with client=true execute immediately when clicked, before any form submission. Server-side actions (client=false) only run after the form submits successfully, making them unsuitable for form validation or immediate user feedback.

⚠️

The condition field accepts server-side JavaScript but executes in a limited context. You cannot access client-side variables like g_form or g_user from condition scripts. Use role-based security or field value conditions instead of complex JavaScript when possible.

The order field controls button sequence but only within the same action type (form_button, list_banner_button, etc.). Mixed action types follow ServiceNow's internal ordering rules regardless of your order values.
Form context UI Actions inherit the current GlideRecord automatically in server-side scripts, but list context actions do not. Always verify the execution context before accessing current variables in your action scripts.
The script field has a 8000 character limit. Large scripts should be moved to Script Includes and called from the UI Action to avoid truncation and improve maintainability.

⚠️

UI Actions with show_insert=false but form_style=true will still appear on new record forms if no other UI Actions exist for that table. ServiceNow always shows at least one submit mechanism on forms.

Role-based conditions in UI Actions are case-sensitive and must match exactly. The role admin is different from Admin in condition evaluations.
Performance trap: condition scripts execute every time the form loads or refreshes. Expensive operations like web service calls or complex database queries in conditions will degrade user experience significantly.

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_db_object table is the primary relationship for UI Actions, linked through the table field. This relationship determines which tables display specific UI Actions and enables table inheritance for actions. Global UI Actions (where table is empty) appear across all forms, while table-specific actions only appear on their designated tables and extending tables.

The sys_ui_view and sys_user_role tables are frequently joined when building dynamic UI Action queries. View relationships control which form contexts display actions, while role relationships determine user access. Developers often query these three tables together when building role-based navigation or implementing approval workflows that require different buttons for different user types.

The sys_ui_action_role many-to-many relationship table connects UI Actions to specific roles, enabling granular access control. When building complex security models or auditing which users can access specific actions, developers query both sys_ui_action and sys_ui_action_role together to understand the complete access picture.

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 identifier for the UI Action, used in scripts and references. Must be unique per table and automatically becomes the button's DOM element ID.
table	string	Table	Table name where this UI Action appears. Empty value creates a global action that appears on all tables unless overridden by table-specific actions.
action_name	string	Action name	Defines the form submission action for form buttons. Common values include 'insert', 'update', 'delete'. Only applies when form_style is true.
active	boolean	Active	Controls whether the UI Action appears in any interface. Inactive actions are completely hidden but preserve their configuration for future reactivation.
client	boolean	Client	Determines execution context: true for client-side JavaScript (immediate execution), false for server-side (executes after form submission). Cannot be changed after creation.
condition	string	Condition	Server-side JavaScript that determines UI Action visibility. Evaluates in limited context without access to client-side variables like g_form.
form_style	boolean	Form button	Shows the action as a form submit button (Save, Update, etc). Form style actions trigger form submission and can change record state.
list_style	boolean	List banner button	Displays the action in the list banner above the list view. List actions typically operate on selected records or provide list-wide functionality.
list_choice	boolean	List choice	Adds the action to the context menu (right-click) for individual list rows. Choice actions operate on single records within list views.
form_link	boolean	Form link	Shows the action as a related link in the form's Related Links section. Form links typically navigate to related records or external resources.
form_context_menu	boolean	Form context menu	Includes the action in the form's right-click context menu. Context menu actions provide quick access to common operations without cluttering the button bar.
script	string	Script	JavaScript code that executes when the action is triggered. 8000 character limit; longer scripts should use Script Includes for maintainability.
order	integer	Order	Controls display sequence within the same action type (form buttons, list buttons, etc). Lower numbers appear first, but mixed action types follow platform ordering rules.
show_insert	boolean	Show on insert	Controls visibility on new record forms. False hides the action during record creation but shows it on existing records.
show_update	boolean	Show on update	Controls visibility on existing record forms. False hides the action when editing saved records but shows it during initial creation.
onclick	string	Onclick	Client-side JavaScript that executes before the main script. Primarily used for form validation or confirmation dialogs that may prevent action execution.
view	reference	View	Reference to sys_ui_view that restricts action visibility to specific form views. Empty value shows the action in all views for the target table.
ui_type	choice	UI Type	Defines action appearance and behavior. Values include '0' (button), '1' (link), '11' (tab). Controls visual styling and interaction patterns.
hint	string	Hint	Tooltip text that appears when users hover over the action. Supports HTML formatting and can include dynamic content through client-side evaluation.

Common Queries

Get all active UI Actions

var gr = new GlideRecord('sys_ui_action');
gr.addQuery('active', true);
gr.orderBy('table');
gr.orderBy('name');
gr.query();

while (gr.next()) {
    gs.info('Action: ' + gr.getValue('name') + 
            ' on table: ' + gr.getValue('table'));
}

Find form buttons for incident table with specific roles

var gr = new GlideRecord('sys_ui_action');
gr.addQuery('active', true);
gr.addQuery('table', 'incident');
gr.addQuery('form_style', true);
// Join to role table to check access
var qc = gr.addJoinQuery('sys_ui_action_role', 'sys_id', 'ui_action');
qc.addQuery('role.name', 'itil');
gr.query();

// Group by action to avoid duplicates from role joins
var actions = {};
while (gr.next()) {
    if (!actions[gr.sys_id.toString()]) {
        actions[gr.sys_id.toString()] = gr.getValue('name');
        gs.info('ITIL Form Button: ' + gr.getValue('name'));
    }
}

Find UI Actions that modify specific field values

var gr = new GlideRecord('sys_ui_action');
gr.addQuery('active', true);
gr.addQuery('script', 'CONTAINS', 'state');
gr.addQuery('script', 'CONTAINS', 'setValue');
// Look for actions that change state field values
gr.addQuery('table', 'IN', 'incident,problem,change_request');
gr.query();

while (gr.next()) {
    // Check if this action actually modifies state
    var script = gr.getValue('script');
    if (script.indexOf('state') > -1 && script.indexOf('setValue') > -1) {
        gs.info('State-modifying action: ' + gr.getValue('name') + 
                ' on ' + gr.getValue('table'));
    }
}

Count UI Actions by table and type

var ga = new GlideAggregate('sys_ui_action');
ga.addQuery('active', true);
ga.addNotNullQuery('table'); // Exclude global actions
ga.addAggregate('COUNT');
ga.groupBy('table');
ga.groupBy('form_style');
ga.groupBy('list_style');
ga.query();

while (ga.next()) {
    var table = ga.getValue('table');
    var isFormButton = ga.getValue('form_style') == '1';
    var isListButton = ga.getValue('list_style') == '1';
    var count = ga.getAggregate('COUNT');
    
    var type = isFormButton ? 'Form' : (isListButton ? 'List' : 'Other');
    gs.info(table + ' - ' + type + ' actions: ' + count);
}

Wrong vs right way to query by condition content

// WRONG - conditions are JavaScript code, not field values
var wrong = new GlideRecord('sys_ui_action');
wrong.addQuery('condition', 'current.state == 2');
wrong.query(); // Returns nothing - exact match required

// RIGHT - use CONTAINS for condition script content
var right = new GlideRecord('sys_ui_action');
right.addQuery('active', true);
right.addQuery('condition', 'CONTAINS', 'current.state');
right.addQuery('condition', 'CONTAINS', '== 2');
right.query();

while (right.next()) {
    // Verify the condition actually checks state == 2
    var condition = right.getValue('condition');
    if (condition && condition.indexOf('current.state') > -1) {
        gs.info('Found state condition in: ' + right.getValue('name'));
    }
}

Related Tables

sys_db_object sys_user_role

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