What This Table Is

The sys_trigger table stores all scheduled jobs in ServiceNow — background scripts that execute on cron schedules. Every time you create a Scheduled Script Execution or use the Job Scheduler, a record lands here with the script content, timing configuration, and execution state. This table is the backbone of ServiceNow's job scheduling system, handling everything from data imports to cleanup routines.

Owned by the Platform module, this table supports the entire scheduled execution process end-to-end. When the scheduler engine runs, it queries active records, executes the JavaScript stored in the script field, and updates the state and timing fields based on execution results. Failed jobs remain active for retry unless manually disabled.

This table doesn't extend any parent table — it's a standalone system table. No tables extend sys_trigger either, but it has a tight relationship with syslog for execution logging and sys_cluster_state for node-specific job distribution in clustered environments.

Enterprise instances typically see 200-500 records in this table. Performance is generally good since the scheduler queries by active and next_action fields, which are indexed. However, avoid queries that scan the script field contents — it's a large text field without indexing.

When You'll Script Against This Table

You'll hit this table most often in Script Includes that manage job lifecycles, Background Scripts that monitor job health, and Business Rules that trigger scheduled maintenance tasks. Scheduled jobs themselves commonly query this table to check if related jobs are running before proceeding. Job monitoring dashboards frequently pull from this table to display execution status and timing.

Access requires the admin role for full CRUD operations. The schedule_admin role provides more targeted access for job management. Read access is tightly controlled since scheduled scripts can contain sensitive automation logic.

  • Creating jobs programmatically for dynamic scheduling needs
  • Disabling jobs during maintenance windows or system changes
  • Monitoring job execution patterns and failure rates
  • Checking job state before running dependent operations
  • Updating job timing or cron expressions based on business rules
  • Building custom job scheduling interfaces or workflows
  • Bulk operations on job collections during migrations

Table Gotchas

⚠️

The active field doesn't mean 'currently running' — it means 'scheduled to run'. Use state field to check execution status. Active jobs can have state='0' (Ready) or state='1' (Running).

⚠️

The next_action datetime field uses the server timezone, not the user's timezone. Always use GlideDateTime for comparisons or you'll get timing logic wrong.

  • The trigger_type field determines execution behavior: '0' for run once, '1' for repeat. But one-time jobs don't auto-delete after running — they stay active until manually disabled.
  • Modifying the script field on running jobs can cause unpredictable behavior. Always disable first, modify, then re-enable.
⚠️

Jobs with invalid cron expressions in conditional_script field will fail silently. The system doesn't validate cron syntax on save — only at execution time.

  • The run_as field reference can become invalid if the user is deactivated, causing jobs to fail with cryptic permission errors.
  • Querying by name field can return duplicates — names aren't enforced as unique. Always include additional filters like active=true for reliable results.
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.

No spam · Unsubscribe anytime

Related Tables

The syslog table is the primary companion — every scheduled job execution creates log entries there. You'll constantly join these tables to correlate job definitions with their execution history, error messages, and performance metrics. The sys_user table links through the run_as field to determine execution context and permissions.

For clustered environments, sys_cluster_state determines which node executes which jobs. The sys_trigger_transaction table tracks job execution transactions for advanced monitoring scenarios. When building comprehensive job management solutions, you'll often query sys_properties for scheduler configuration settings like maximum concurrent jobs and execution timeouts.