Trigger

What It Is

A Trigger is the entry point for every Flow in ServiceNow, defining the specific event or condition that initiates automated processing. Unlike Business Rules or Script Includes that execute within the database layer, triggers operate within the Flow Designer execution engine and provide a declarative interface for automation initiation. They solve the fundamental problem of when and how to start automated processes, replacing complex scripting with configuration-driven event detection. The trigger captures the initial context—whether it's a record being created, a scheduled time arriving, or an external system making an API call—and passes this data as the starting point for all subsequent Flow activities.

Triggers live within the Flow Designer application (com.glide.hub.flow_designer) and are stored in the sys_hub_flow_base table with type trigger. They operate at the platform level, above the database transaction layer where Business Rules execute, which means they can orchestrate multiple database transactions and external system calls without being constrained by rollback scenarios. The trigger infrastructure includes dedicated processing nodes for execution and maintains its own queue system separate from scheduled jobs or email processing. This architectural separation allows triggers to maintain state across complex, long-running processes while providing built-in error handling and retry capabilities that traditional server-side scripts lack.

The underlying execution model depends on the trigger type: record-based triggers register with the sys_trigger framework and fire through database events, while scheduled triggers integrate with the ServiceNow job scheduler. Inbound email triggers connect to the email processing pipeline, and REST API triggers create dedicated endpoints in the api/now/table namespace. Each trigger type maintains its own registration mechanism with the platform's event system, ensuring that the appropriate Flow context gets created when the triggering condition occurs. The trigger also establishes the security context for the entire Flow execution, inheriting permissions from either the triggering user or a designated system account depending on the configuration.

You cannot function without triggers in any scenario requiring event-driven automation that spans multiple systems, involves human interaction, or needs to maintain state across time. While Business Rules handle immediate database-level responses, triggers are essential for processes like multi-step approvals that might take days to complete, integrations that require external API calls with error handling and retries, or any automation that needs to pause and wait for external events. Service catalog fulfillment, incident escalation workflows, onboarding processes, and compliance auditing all require the stateful execution model that only Flow triggers provide. The alternative—building equivalent functionality with Business Rules, Scheduled Jobs, and custom scripts—creates a maintenance nightmare of interdependent components without centralized error handling or process visibility.

Platform owners typically define the trigger strategy and governance policies, including which tables can have Flow automation and performance guidelines for trigger frequency. Application administrators configure the actual triggers, defining the conditions and initial Flow steps, while developers might create custom trigger conditions using script conditions or build specialized Application triggers for integration scenarios. The relationship is hierarchical—platform owners set the guardrails, admins implement the business logic, and developers extend capabilities when declarative options aren't sufficient. This division ensures that business users can build automation without compromising platform stability while providing escape hatches for complex technical requirements.

Recent releases have significantly improved trigger performance and reliability. Vancouver introduced enhanced trigger condition evaluation that reduces database queries for record-based triggers, while Xanadu added support for batch processing in scheduled triggers and improved error recovery mechanisms. The most significant change in recent versions is the introduction of Flow execution insights, providing detailed performance metrics and bottleneck identification for trigger-initiated Flows. Xanadu also enhanced the trigger testing framework, allowing admins to simulate trigger events without creating actual records or waiting for scheduled execution, dramatically improving development and troubleshooting workflows.

Where to Find and Configure It

The primary configuration location is Process Automation > Flow Designer, where you create new Flows and configure their triggers as the first step in the Flow canvas. Every Flow must start with exactly one trigger, selected from the trigger palette on the left side of the designer interface. You can also access trigger configuration through System Applications > Studio when working within a scoped application, where triggers appear as Flow resources under your application scope. In App Engine Studio, triggers are configured through the Logic and automation > Flows section, providing a simplified interface for citizen developers.

To see triggers in action, navigate to Process Automation > Flow Designer > Execution Details to view triggered Flow executions, or check System Logs > Flow Logs for detailed trigger firing information. The underlying data lives in sys_hub_flow_base for trigger definitions and sys_flow_context for execution instances. For REST API triggers specifically, the generated endpoints appear in System Web Services > REST API Explorer under the Flow Designer namespace. Scoped applications create triggers within their application scope, while global Flows create system-level triggers accessible across all applications.

How It Works Step by Step

When you configure a trigger, ServiceNow registers the event condition with the appropriate platform subsystem—database events for record-based triggers, scheduler for time-based triggers, email processor for inbound email, or web service framework for API triggers. The trigger definition includes the event criteria, any filtering conditions, and the Flow to execute when triggered. ServiceNow stores this configuration and creates the necessary infrastructure connections to monitor for the specified events. The trigger remains dormant until the registered event occurs, at which point the platform's event detection mechanism identifies the match and initiates Flow execution.

During execution, the trigger creates a Flow execution context containing all relevant data from the triggering event—the record that changed, the scheduled time that arrived, the email that was received, or the API payload that was submitted. This context becomes the data foundation for the entire Flow, with subsequent actions and conditions able to reference trigger data through data pills in the Flow Designer interface. The trigger also establishes security context, determining which user permissions apply to the Flow execution and whether the Flow runs as the triggering user or under system privileges.

The Execution Order

1. Event detection: Platform subsystem identifies that trigger condition is met
2. Trigger evaluation: System verifies any additional conditions or filters configured on the trigger
3. Context creation: Flow execution context is created with trigger data and security permissions
4. Queue placement: Execution request is placed in the Flow processing queue
5. Flow initiation: Flow Designer engine picks up the execution and begins processing the first action
6. Data binding: All trigger data pills become available to subsequent Flow steps through the execution context

// Example trigger condition script for Incident record
// Triggers only when Priority changes to 1-Critical
// and Assignment Group is not empty

(function executeRule(current, previous) {
    // Check if Priority changed to 1 (Critical)
    if (current.priority == '1' && previous.priority != '1') {
        // Ensure Assignment Group is populated
        if (!gs.nil(current.assignment_group)) {
            // Additional check: only during business hours
            var schedule = new GlideSchedule('08a5831cc0a8016400b98a06818d57c7');
            if (schedule.isInSchedule()) {
                return true;
            }
        }
    }
    return false;
})(current, previous);

Real-World Scenarios

Critical Incident Escalation with Time-Based Follow-up

Business requires immediate notification to management when Critical incidents are created, followed by automatic escalation if not resolved within 2 hours. Standard Business Rules can't handle the time-based follow-up without creating complex scheduled job dependencies.

Create a Record-based trigger on incident table with condition Created and filter Priority is 1 - Critical. Add immediate notification action to send alerts to management group. Follow with Wait for Condition action checking if State is 6 - Resolved with timeout of 2 hours. Add escalation actions after the timeout path to assign to next-level support and notify executives.

Watch for scope conflicts if your incident table has customizations—the trigger might not see custom fields unless the Flow runs in the same scope. Test with actual Critical incidents to verify timing accuracy, and ensure the Wait for Condition action has appropriate permissions to check incident state changes. Consider adding a condition to prevent escalation if incident is already assigned to executive-level groups.

Service Catalog Approval with Dynamic Assignment

Service catalog requests over $5000 require approval from the requester's department head, then finance approval if over $10000, with automatic fallback to designated alternates if approvers don't respond within 3 business days. The approval chain must be dynamic based on organizational hierarchy.

Create Record-based trigger on sc_req_item with Created condition and filter Price is greater than 5000. Use Look up Record action to find requester's manager from sys_user.manager relationship. Add Ask for Approval action with 3-day timer and manager as approver. Create conditional branch: if price > $10000 and manager approved, add second Ask for Approval for finance team. Include Error handling for missing manager data with assignment to default approval group.

The trigger fires immediately when catalog items are submitted, so verify your price comparison logic accounts for currency formatting and null values. Test manager lookup thoroughly—missing or inactive managers will break the Flow unless you handle the null case. Configure notification templates for approval requests to include relevant catalog item details, and ensure the finance approval group has proper permissions to view and approve high-value requests.

Automated Vendor Integration via Inbound Email

Third-party monitoring system sends incident alerts via email to a dedicated ServiceNow address, requiring automatic parsing of email content to create incidents with proper categorization and priority assignment based on alert severity keywords. Manual processing creates delays and inconsistent categorization.

Create Inbound Email trigger with email conditions To contains alerts@yourcompany.service-now.com and From contains monitoring.vendor.com. Add Script action to parse email body for severity keywords like 'CRITICAL', 'WARNING', 'INFO' and map to incident priority values. Use Create Record action to generate incident with parsed subject as short description, email body as description, and calculated priority. Add lookup table for keyword-to-category mapping to ensure consistent assignment group selection.

Email parsing is fragile—vendor format changes will break your automation, so build robust error handling and consider using regex patterns instead of simple keyword matching. Configure email account security carefully to prevent spam from triggering false incidents. Test with actual vendor email formats and monitor for parsing failures that create incidents with missing or incorrect data.

The Classic Mistake

// Record trigger on incident table
// Condition: (empty)
// Table: incident
// Action: Any

// Flow script step that updates the record
var gr = new GlideRecord('incident');
gr.get(current.sys_id);
gr.work_notes = 'Flow processed at ' + new GlideDateTime();
gr.update();

// This creates an infinite loop:
// Update -> Trigger -> Flow -> Update -> Trigger -> Flow...

This configuration creates an infinite execution loop because every Flow update triggers another Flow execution. Users see their browser freeze, records become locked with Record is being modified by another user errors, and system performance degrades rapidly. ServiceNow's Flow engine keeps queuing new executions until the system hits execution limits or administrators disable the Flow. The mistake is non-obvious because the initial Flow execution appears to work correctly—the problem only emerges when the Flow modifies the triggering record.

// Record trigger on incident table
// Condition: state.changes() && state == '6'
// Table: incident
// Action: Updated

// Flow script step with loop prevention
if (trigger.current.state == '6' && trigger.previous.state != '6') {
    var gr = new GlideRecord('incident');
    gr.get(trigger.current.sys_id);
    gr.work_notes = 'Closure processing completed';
    gr.setWorkflow(false);  // Prevents triggering other flows
    gr.update();
}

When to Use This vs Alternatives

Flow triggers excel when you need visual workflow design with complex branching logic, external system integration, or when non-technical business users need to understand and modify automation logic. They provide superior debugging capabilities compared to Business Rules and handle asynchronous operations naturally.

Choose Flow Triggers When

You need multi-step approval processes, REST API callouts to external systems, or complex conditional logic that would require dozens of nested if-statements in a Business Rule. Flow triggers handle user interaction steps, wait conditions, and parallel processing that Business Rules cannot accomplish. The visual flow designer makes troubleshooting and modification significantly easier for complex automation scenarios.

Use Business Rules Instead When

You need guaranteed synchronous execution, simple field calculations, or performance-critical operations on high-volume tables. Business Rules execute faster and consume fewer resources for straightforward automation like setting default values, performing calculations, or enforcing data validation. Flow triggers add execution overhead that becomes significant on tables processing thousands of records daily.

Use Both Together When

You need immediate data validation through Business Rules plus complex downstream processing through Flow triggers. Use Business Rules for critical field validation and calculations that must complete before the record saves, then trigger Flows for notifications, integrations, and multi-step processes. Set different execution order values to control the sequence and prevent conflicts between the two automation types.

Platform Interactions & Side Effects

• Creates entries in sys_flow_context table for each execution, including trigger data, execution state, and variable values that persist until Flow completion
• Bypasses Access Control Rules (ACLs) during Flow execution—Flows run with elevated privileges regardless of the triggering user's permissions
• Interacts with Business Rules through execution order—Business Rules with before timing complete before Record triggers fire
• Updates sys_audit table when Flow makes record changes, with user_name showing as 'system' rather than the original user
• Breaks Update Set capture for Flow modifications—changes made through Flow execution don't automatically appear in Update Sets
• Notifications triggered by Flow record updates execute with Flow context, causing ${mail_script} variables to reference Flow variables instead of record fields
• Schedule-based triggers create entries in sys_trigger table with next execution times, causing scheduled job conflicts if system clocks drift
• Performance impact increases exponentially with nested Flow calls—each sub-flow creates additional sys_flow_context records and execution threads
• REST API triggers create session records in sys_user_session table that persist beyond Flow execution, potentially causing session limit issues
• Import Set transforms ignore Flow triggers completely—data imported through sys_import_set_row processing won't trigger Record-based flows

Debugging and Troubleshooting

Flow trigger failures typically manifest as silent automation failures—users expect something to happen but see no results, no error messages, and no obvious indication that a Flow was supposed to execute. Common symptoms include missing notifications, records that remain in incorrect states, and approval processes that never start. Unlike Business Rule failures that often generate JavaScript errors, Flow trigger problems require checking specific execution logs and Flow context records.

Primary debugging locations include System Logs > Flow for execution details, Flow Designer > Executions for visual execution traces, and the sys_flow_context table for detailed trigger data and variable values. Look for error messages like "Trigger condition failed evaluation" indicating condition script problems, or "Flow execution suspended" suggesting approval or wait steps that never complete.

Schedule-based triggers produce specific error patterns in System Log > Scheduled Jobs with messages like "Trigger execution failed: No active Flow found" when Flows are deactivated but schedules remain active. REST API triggers log authentication failures in System Log > REST as "Invalid API key" or "Trigger endpoint not found" errors. Enable the com.glide.flow.log_level system property set to 'debug' for detailed execution tracing.

Diagnostic Checklist:

• Verify Flow is Active and Published in Flow Designer > Flow properties
• Test trigger condition script in Scripts - Background with sample record data
• Check sys_flow_context records for recent executions and error states
• Confirm trigger table and action settings match the actual record operation being performed
• Review execution history in Flow Designer > Executions for step-by-step failure analysis
• Validate REST API trigger endpoints with Postman or curl, checking authentication and payload format
• Examine sys_trigger records for Schedule-based triggers to verify next run times and execution states

Quick Reference

• Maximum 50 concurrent Flow executions per instance—additional triggers queue in sys_flow_context with state 'waiting'
• Record triggers fire after database commit—rolling back the transaction doesn't prevent Flow execution
• Schedule-based triggers use server timezone, not user timezone—CRON expressions execute based on instance location
• REST API triggers timeout after 30 seconds—long-running Flows must use asynchronous execution patterns
• Trigger conditions cannot access gs.getUser() or session variables—use current.sys_created_by instead
• Inbound Email triggers require exact Subject contains matches—partial matches or regex patterns don't work
• Application triggers only fire for records created through the specified application scope—cross-scope updates ignored
• Flow execution continues even if triggering record gets deleted—use trigger.current.isValidRecord() to verify existence
• Clone operations create two trigger executions—one for insert, one for the subsequent update with cloned values
• Flow context records in sys_flow_context auto-delete after 30 days via scheduled cleanup job 'Flow Context Cleaner'