Scheduled Script Executions

Scheduled Script Executions in ServiceNow CAD

Scheduled Script Executions in ServiceNow

Why Is This Important?
Scheduled Script Executions are a critical component of application automation in ServiceNow. They allow administrators and developers to automate recurring tasks, data maintenance, integrations, and reporting processes without manual intervention. For the ServiceNow Certified Application Developer (CAD) exam, understanding how scheduled jobs work is essential because questions frequently test your ability to identify the correct automation mechanism for a given scenario. Knowing when and how to use scheduled scripts distinguishes a competent developer from one who relies solely on manual processes.

What Are Scheduled Script Executions?
Scheduled Script Executions refer to the ability to run server-side JavaScript at predefined times or intervals within the ServiceNow platform. The primary mechanism for this is the Scheduled Job (also known as Scheduled Script Execution), which is found under System Definition > Scheduled Jobs in the application navigator.

There are several types of scheduled jobs in ServiceNow:

1. Run a Script (Custom) – Allows you to write and execute custom server-side JavaScript on a defined schedule.
2. Run a Flow – Executes a Flow Designer flow on a schedule.
3. Run a Fix Script – Runs a predefined fix script at a scheduled time.
4. Generate Multiscore Report Cards – Specific to Performance Analytics.
5. Other Out-of-Box Scheduled Jobs – ServiceNow ships with many pre-configured scheduled jobs for system maintenance (e.g., cleaning up old logs, sending notifications, rotating encryption keys).

How Do Scheduled Script Executions Work?

1. Creating a Scheduled Job
To create a scheduled script execution:
- Navigate to System Definition > Scheduled Jobs
- Click New
- Select the type of scheduled job (most commonly Automatically run a script of your choosing)
- Provide a Name for the job
- Write the server-side Script (using GlideRecord, GlideSystem, and other server-side APIs)
- Define the Run schedule (e.g., Daily, Weekly, Monthly, Periodically, Once, or On Demand)
- Set the Time and Conditional parameters as needed
- Save or submit the record

2. Scheduling Options
ServiceNow offers flexible scheduling options:
- Run Once – Executes the script a single time at the specified date and time.
- Run Daily – Runs every day at the specified time.
- Run Weekly – Runs on specified days of the week.
- Run Monthly – Runs on a specific day of the month.
- Run Periodically – Runs at a defined interval (e.g., every 15 minutes, every 2 hours).
- On Demand – Can be triggered manually via the Execute Now button.

3. Key Fields and Concepts
- Active – A true/false field that determines if the scheduled job is enabled or disabled.
- Conditional – Allows you to specify a condition script that must evaluate to true before the main script runs.
- Run as – Specifies the user context under which the script executes. This is important for security and role-based access.
- Time Zone – The time zone in which the schedule is evaluated. By default, this is the system time zone, but it can be configured per job.
- System ID (sys_id) – Each scheduled job is a record in the sysauto_script table (or related tables depending on the type).

4. Execution Context
Scheduled scripts run on the server side. They have access to all server-side APIs such as:
- GlideRecord – For database queries and operations
- GlideSystem (gs) – For logging, user info, date/time functions
- GlideDateTime – For date and time manipulation
- GlideAggregate – For aggregate queries
- RESTMessageV2 / SOAPMessageV2 – For outbound integrations

They do not have access to client-side APIs (e.g., g_form, g_list, GlideAjax client-side calls).

5. Monitoring and Troubleshooting
- Check the System Logs (System Logs > System Log > All) for output from gs.log() or gs.info() statements.
- Review the Scheduled Job Log for execution history, including start time, end time, and any errors.
- Use gs.info(), gs.warn(), or gs.error() within scripts for debugging.
- The Last run time and Next scheduled run time fields on the scheduled job record help verify execution timing.

6. Common Use Cases
- Data Cleanup – Automatically archiving or deleting old records (e.g., closing stale incidents after 30 days of inactivity).
- Notifications and Reminders – Sending periodic email reminders for overdue tasks.
- Integration Synchronization – Periodically pulling or pushing data to/from external systems via REST or SOAP.
- Report Generation – Generating and distributing reports on a schedule.
- License or Compliance Checks – Running audits on user accounts or software assets at regular intervals.
- Performance Maintenance – Cleaning up system logs, events, or temporary data.

7. Relationship to Other Automation Mechanisms
It is important to understand how scheduled script executions differ from other automation tools:
- Business Rules – Triggered by database operations (insert, update, delete, query) on specific tables. They are event-driven, not time-driven.
- Script Includes – Reusable server-side script libraries that must be called by other scripts. They do not run independently.
- Flow Designer Scheduled Flows – A low-code alternative to scheduled scripts, using Flow Designer triggers and actions. They serve a similar purpose but with a visual interface.
- Events and Script Actions – Event-driven, triggered by gs.eventQueue(). Not time-based.
- UI Actions / Client Scripts – Client-side or hybrid; not relevant to scheduled background automation.

Exam Tips: Answering Questions on Scheduled Script Executions

Tip 1: Identify the Trigger Type
When an exam question describes a scenario requiring automation at a specific time or on a recurring schedule, the answer is almost certainly a Scheduled Job or Scheduled Script Execution. If the scenario describes something triggered by a record change, think Business Rules instead.

Tip 2: Know the Table
Scheduled Script Executions are stored in the sysauto_script table. Other types of scheduled jobs may extend the sysauto table. Be aware of this if questions reference table names.

Tip 3: Remember the Server-Side Context
Scheduled scripts run server-side only. If an answer option suggests using client-side APIs (like g_form or GlideAjax) within a scheduled job, that answer is incorrect.

Tip 4: Understand the Run As Field
The Run as field determines the user context for the script. This affects which records the script can read/write based on ACLs and roles. Exam questions may test whether a scheduled job has the correct permissions to perform its intended operations.

Tip 5: Differentiate from Flow Designer
ServiceNow is increasingly emphasizing Flow Designer. Know that scheduled flows (using a Scheduled trigger in Flow Designer) can accomplish similar tasks to scheduled script executions, but they are configured through the Flow Designer interface rather than by writing raw scripts. If a question asks about a no-code or low-code approach to scheduling, think Flow Designer.

Tip 6: Conditional Execution
Remember that scheduled jobs can include a Conditional script. This script runs first, and only if it evaluates to true does the main script execute. This is useful for scenarios where you only want the job to run under specific circumstances.

Tip 7: Watch for On Demand vs. Scheduled
Some questions may present scenarios where a task needs to be run immediately or manually triggered. Scheduled jobs support an Execute Now option for on-demand execution. Also, a scheduled job set to run once in the past will execute immediately upon being made active.

Tip 8: Logging and Debugging
If an exam question asks about troubleshooting a scheduled job, remember that you should check the System Log and use gs.info() or gs.log() for debugging. The scheduled job record itself also tracks the last run time and next run time.

Tip 9: Active Field
A common exam trap involves a scheduled job that is not running. Always check if the Active field is set to true. An inactive scheduled job will not execute regardless of its schedule configuration.

Tip 10: Best Practices to Remember
- Keep scheduled scripts efficient to avoid performance issues.
- Avoid long-running queries without proper filters.
- Use GlideRecord best practices (e.g., setLimit(), addQuery() with indexed fields).
- Log meaningful information for troubleshooting.
- Test scheduled jobs in sub-production environments before deploying to production.

Summary
Scheduled Script Executions are a foundational automation tool in ServiceNow that enable time-based, recurring, or on-demand execution of server-side scripts. For the CAD exam, focus on understanding when to use scheduled jobs versus other automation mechanisms, the configuration options available, the server-side execution context, and troubleshooting techniques. Always look for time-based triggers in exam scenarios as your cue that a Scheduled Script Execution is the correct answer.