Scheduled Script Executions and Events Objectives

In this module you will learn to:

 Create and test Scheduled Script Executions (Scheduled Jobs)

 See the schedule and determine if jobs are on the schedule

 Determine which events have been generated

 Register events in the event repository

 Generate and debug events

 Respond to events with Script Actions

What is a Scheduled Script Execution?

Scheduled Script Executions, also known as Scheduled Jobs, are automated, server-side script
logic which executes at a specific time or on a recurring basis.

Use Scheduled Script Executions when application processes require script logic to be executed
based on a time schedule. For example:

 Periodically query a database table

 Find records with overdue Due dates

 Find records with Due dates in the near future

 Locate all requests from a particular user

 Look for records which have been in a certain state, such as resolved, too long

 Update records

 Set the State field value to Closed Complete after a fixed time has elapsed

 Assign unassigned records to a user

 Delete or re-assign all records created by a user

DEVELOPER TIP: Although not the primary use case, Scheduled Script Executions are useful
for testing server-side script logic because they can be configured to execute on demand.

Creating a Scheduled Script Execution

The procedure for adding files to an application in Studio is the same regardless of file type:

1. Click the Create Application File button.

2. Choose the new file type, in this case, Scheduled Script Execution.

3. Configure the new file.

The Scheduled Script Execution configuration has fields which are common to all Scheduled
Script Executions.
  Name: Name of the Scheduled Script Execution

 Active: When selected, the Scheduled Script Execution is enabled

 Run: The periodicity for executing the script logic

 Application: Name of the Scheduled Script Execution’s application

Some Scheduled Script Execution configuration options are dependent on the value in the Run
field. All time fields use a 24-hour clock (HH:mm:ss): 23:00:00 = 11:00:00 PM

Daily:

Weekly:
Monthly:

To run a Scheduled Script Execution on the last day of the month, configure a monthly
Scheduled Script Execution set to run on 31. The Scheduled Script Execution will run on the last
day of the month even for months with fewer than 31 days.

Periodically:

The configuration shown executes the Scheduled Script Execution logic every hour on the hour.

Once:

Scheduled Script Executions configured to run once execute on the specified date and time.

On Demand:
On Demand Scheduled Script Executions run when an administrator clicks the Execute Now
button.

Testing Scheduled Script Executions

To test a Scheduled Script Execution you could, of course, wait until the next scheduled
execution to see if the script(s) worked. Doing so could lead to a long development cycle,
especially for scripts which run quarterly or annually. To test a Scheduled Script Execution, use
the Execute Now button. The Execute Now button is available after saving a Scheduled Script
Execution.

The Execute Now button is available for all Scheduled Script Execution types such as monthly
and daily. On demand Scheduled Script Executions do not run unless an administrator executes
them using the Execute Now button.

Selecting the Execute Now button puts the Scheduled Script Execution on the schedule to be run
asynchronously as soon as possible. The scheduler thread picks up the Scheduled Script
Execution from the schedule and executes the script logic.

What is on the Schedule?

To see the Scheduled Script Executions on the schedule for today, use the Application Navigator
in the main ServiceNow browser window to open System Scheduler > Scheduled Jobs >
Today’s Scheduled Jobs.
Today’s schedule shows what is on today’s schedule from now until the end of the day
(23:59:59). The Today’s Scheduled Jobs module does not show jobs that were on today’s
schedule which have already completed execution.

 Name: Scheduled Script Execution (Scheduled Job) name.

 Next action: When the Scheduled Script Execution is scheduled to run

 Trigger type: Periodicity of execution

 Job ID: Type of job

 State: Can be Ready, Running, Error, or Queued

Scheduled Jobs in the Ready state are ready to be picked up by the scheduler when the Next
action time arrives. If the word Ready appears in Red it means the Next action time is past and
the job has not yet executed. If jobs are scheduled to run at the same time, it is expected that
some jobs will miss their Next action time while waiting for other jobs to finish. The scheduler
will run the jobs as close to their Next action time as resources allow.

Exercise: Create a Scheduled Script Execution

In this exercise you will create and test a Scheduled Script Execution to find overdue NeedIt
tasks.

Preparation

Ordinarily NeedIt Task records are created by a workflow when NeedIt requests are approved.
For this exercise you need several NeedIt Task records, some with overdue Due dates. You will
create NeedIt Task records manually.

1. In the main ServiceNow browser window (not Studio), use the Application Navigator to
open NeedIt > NeedIt Tasks. You may or may not have NeedIt Task records already.

2. Create an overdue NeedIt Task record with the State field value Open.

a. Click the New button.

b. Configure the NeedIt Task.

Assigned to: Beth Anglin

Due date: Choose a date of your choice that is in the past

State: Open

Short description: Overdue

Click the Submit button.

Create a NeedIt Task for the future with the State field value Open.

. Click the New button.

a. Configure the NeedIt Task.

Assigned to: Beth Anglin

Due date: Choose a date of your choice that is in the future

State: Open
 Short description: Not overdue

Click the Submit button.

Create a NeedIt Task for the past with the State field value Work in Progress.

. Click the New button.

a. Configure the NeedIt Task.

Assigned to: Beth Anglin

Due date: Choose a date of your choice that is in the past

State: Work in Progress

Short description: Overdue

Click the Submit button.

Create a NeedIt Task for the past with the State field value Closed Complete.

. Click the New button.

a. Configure the NeedIt Task.

Assigned to: Beth Anglin

Due date: Choose a date of your choice that is in the past

State: Closed Complete

Short description: Due date in past but record is closed

Click the Submit button.

Create a Scheduled Script Execution

1. If the NeedIt application is not open in Studio from the last exercise, open it now.

a. In the main ServiceNow browser window use the Application Navigator to open System
Applications > Studio.

b. In the Load Application dialog, click the NeedIt application.

Create a Scheduled Script Execution.

In Studio, select the Create Application File button.

In the Filter… field enter the text Scheduled OR select Server Development from the categories
in the left hand pane.

Select Scheduled Script Execution in the middle pane as the file type then select
the Create button.

Configure the Scheduled Script Execution:

Name: Find NeedIt Overdue Tasks

Active: Selected (checked)

Run: Daily

Time: 08 00 00

Copy this script and paste it into the Run this script field.

// Get today's time and date

var rightNow = new GlideDateTime();

// Query the database for NeedIt Task records with Due date field values older

// than the current time. Only return NeedIt Task records that do not have

// a State field value of Closed Complete.

var overdueNITasks = new GlideRecord('x_58872_needit_needit_task');

 overdueNITasks.addQuery('due_date','<=',rightNow);

overdueNITasks.addQuery('state','!=',3);

overdueNITasks.query();

// Write a log message for each overdue NeedIt Task Record

while(overdueNITasks.next()){

gs.info("Overdue NeedIt Task record = " + overdueNITasks.number);

Click the Submit button to save the Scheduled Script Executions.

Examine the script to make sure you understand what it does.

QUESTION: Which of the NeedIt Task records you created should be returned by the Scheduled
Script Execution script query? If you aren’t sure, scroll to the Answers section at the bottom of
this page.

Test the Scheduled Script Execution

1. Force the Scheduled Script Execution to run by clicking the Execute Now button in the
Scheduled Script Execution form.

2. Switch to the main ServiceNow browser window and use the Application Navigator to
open System Logs > System Log > Application Logs.

3. Look for the Overdue NeedIt Task record messages. Do you see messages for the records
you expected? If you don’t see any messages, the Scheduled Job may not have finished
execution yet. To refresh the list, click the Additional Actions menu ( ) and select
the Refresh List menu item.

Challenge

Create a Scheduled Script Execution to query the database for NeedIt Task records with Due
dates between now and 24 hours from now.

 Use the Find Overdue NeedIt Tasks Scheduled Script Execution script as a model

 Call the new Scheduled Script Execution Find NeedIt Tasks Due Soon.

 Make the Scheduled Script Execution run Daily at 8:05 AM.

  The NeedIt Tasks should not have a State field value of Closed Complete

 Test the Scheduled Script Execution to make sure it works. You may have to create or
modify NeedIt Tasks to meet the criteria of between now and 24 hours from now.

There are several possible script solutions. If you get stuck, see the Answers section at the
bottom of this page for a possible solution.

Answers

Question: Which of the NeedIt Task records you created should be returned by the Scheduled
Script Execution script query?

Answer: The two NeedIt Task records with Due dates in the past and the State value of Open or
Work in Progress should be returned by the query. Both of the records have a Short description
value of Overdue. If you had existing NeedIt Task records from exercises from other modules,
more than two records may be returned.

Challenge: Create a Scheduled Script Execution to query the database for NeedIt Task records
with Due dates between now and 24 hours from now.

// Get today's time and date

var rightNow = new GlideDateTime();

// Query the database for NeedIt Task records with Due date field values within

// 24 hours from now. Only return NeedIt Task records that do not have
// a State field value of Closed Complete.

var dueSoon = new GlideRecord('x_58872_needit_needit_task');

dueSoon.addQuery('due_date','>=',rightNow);

dueSoon.addQuery('due_date','<',gs.hoursAgo(-24));

dueSoon.addQuery('state','!=',3);

dueSoon.query();

// Write a log message for each overdue NeedIt Task Record

while(dueSoon.next()){

gs.info("NeedIt Task due soon record = " + dueSoon.number);

This solution uses the GlideSystem hoursAgo() method. When passed a positive number, the
method looks into the past. When passed a negative number, the method looks into the future. It
may seem counterintuitive for a negative number to reference the future. The method is
hoursAgo() which is why positive numbers are in the past. Two hours ago is a positive number.

What are Events?

Events are an indication in ServiceNow that something notable has occurred. Events can be
generated by server-side scripts, workflows, ServiceNow processes, or by user actions such as:

 Impersonating a user

 Logging in

 Viewing a record

 Modifying a record

Each event is an entry in an event queue and not an action. Unless logic is created to respond to
events, nothing happens with an event after it is generated. Responses can be:

 Email notification

 Script Action (server-side script)

The generalized process for working with events is:

1. Add event to the Event Registry (not needed if you generate an already registered event).

2. Generate the event.

3. Create logic to respond to the event.

Event Registry

ServiceNow can only respond to events which are registered with the Event Registry.
Registering an event lets the ServiceNow processes recognize and respond to the event.

Register events in Studio. The procedure for adding files to an application in Studio is the same
regardless of file type:

1. Click the Create Application File button.

2. Choose the new file type, in this case, Event Registration.

3. Configure the new file.

Configure the event:

 Suffix: Unique part of Event name. Do not use spaces or special characters.

 Event name: Automatically created name for the event.

 Table: Database table for the event.

 Fired By: List of workflows and scripts calling this event. This is used for
troubleshooting only and not for event processing.

 Description: Documents the event purpose. Be sure to put a meaningful description for
future reference. If you alter the meaning of an event, update this field.

 Queue: The event processing queue which manages this event. If left blank the event
goes to the default queue. User-defined queues are addressed on another page in this
module.

Generating Events

There are two ways to generate events:

 Server-side script using the gs.eventQueue() method

 Workflow Create Event activity

gs.eventQueue() Method
The eventQueue() method is part of the GlideSystem server-side API. The eventQueue() method
inserts an event in an event queue. The eventQueue() method is typically passed four parameters
but can also take an optional 5th parameter:

 Event name. Enclose the event name in quotes.

 GlideRecord object, typically current but can be any GlideRecord object from the event’s
table.

 Any value that resolves to a string. This is known as parm1 (Parameter 1). Can be a
string, variable that resolves to a string, or method that resolves to a string.

 Any value that resolves to a string. This is known as parm2 (Parameter 2). Can be a
string, variable that resolves to a string, or method that resolves to a string.

 (Optional) Name of the queue to manage the event.

The logic that responds to an event has access to the passed in GlideRecord object, parm1, and
parm2.

Consider this case:

gs.eventQueue('x_58872_needit.overdueNeedItTask',current,current.number,gs.getUserName());

Notice that the gs.eventQueue method is passed the current object and that parm1 is
current.number. Since current was passed as part of the event, passing current.number in parm1
seems redundant. Why, then, would one do this? The parm1 and parm2 parameters appear in
their resolved form in the Event Log. Having access to a record identifier, such as the record
number, in the logging information can be useful for troubleshooting.
DEVELOPER TIP: If you don’t have values to pass in parm1 or parm2, use gs.getUserName()
and gs.getUserID() so you can see which user triggered the event when looking at the event log.

Use the GlideSystem eventQueueScheduled() method to generate an event with an expiration.

Create Event Workflow Activity

The Create Event workflow activity is part of the Notifications category.

To configure the Create Event workflow activity, select an Event name from the reference list.
Use the Parameter 1 and Parameter 2 script fields to return string values for parm1 and parm2.
The activity automatically passes current as the event’s GlideRecord object. There is no field for
specifying the event queue.
If you want to learn more about Workflow, we recommend you work the Workflow training
module which is part of the Automating Application Logic course.

Checking for Events

Use the Event Log to see which events have been generated. To open the Event Log, use the
Application Navigator in the main ServiceNow browser window to open System Policy >
Events > Event Log.
  Created: Date and time of the event for the locale of the machine running the
ServiceNow instance.

 Name: Name of the event.

 Parm1: Value passed when the event was generated.

 Parm2: Value passed when the event was generated.

 Table: Database table acted on by this event.

 Processed: Date and time the event was processed. This time reflects the locale of the
machine running the ServiceNow instance.

 Processing time: Time taken to process this event in milliseconds.

 Queue: Processor queue name.

Notice that the values of parm1 and parm 2 are resolved in the Event Log. In this example, the
event was generated for a record, NITASK003003 from the NeedIt Task table by user admin.
Having the record number available in the Event Log makes troubleshooting easier.
If there is no value in the Queue column, the event was processed by the default queue. If there is
a value in the Queue column, the event was processed by a custom queue.

This entry has a problem with the record that was passed by the gs.eventQueue() method. The
most likely cause is that the object passed was for the wrong table.

Responding to Events

There are two possible ways to respond to events:

 Email Notification

 Script Action

This module focusses on Script Actions. For information about Email Notifications, we
recommend you work the Notifications module which is part of the Automating Application
Logic course.

Script Actions

Script Actions are event handlers; server-side script logic which executes in response to events.

Create Script Actions in Studio. The procedure for adding files to an application in Studio is the
same regardless of file type:

1. Click the Create Application File button.

2. Choose the new file type, in this case, Script Action.

3. Configure the new file.

  Name: Name of the new Script Action.

 Event name: The event to which the Script Action responds.

 Order: Order of execution of Script Actions for the same event. Order of execution is
from low to high. By convention, but not required, order numbers are 3-digit numbers.

 Active: Select this option to put the Script Action into runtime. This option is not selected
by default.

DEVELOPER TIP: Script Actions are not active by default. Don’t forget to select Active to
enable the Script Action.

There are two scripting fields:

 Condition Script: JavaScript condition for Script to execute. The Script only loads if the
condition tests true.

 Script: Server side JavaScript logic to execute if the condition tests true.

There are two useful objects for Script Action Scripts:

 event

 current

The Script field, but not the Condition field, has access to the event object. To use parm1 or
parm2, reference them as properties on the event object:

if(event.parm2 != 'admin'){ }
Both scripting fields have access to the current object. For Script Actions, current is whichever
object was passed in by the gs.eventQueue() method.

Here is a script fragment from a Business Rule:

gs.eventQueue('x_58872_needit.overdueNeedItTask',previous,current.number,gs.getUserName()
);

Notice the previous object is passed to the event.

In the Script Action, there IS NO PREVIOUS OBJECT. The passed in object is always current
in the Script Action.

Exercise: Create and Generate an Event

In this exercise you will register, generate, and respond to an event. The event will search for
overdue NeedIt Task records.

Preparation

For this exercise you need several NeedIt Task records, some with overdue Due dates. If you do
not have overdue NeedIt Task records, create some now using the same procedure as in the last
Exercise (Exercise: Create a Scheduled Script Execution).

Register an Event

1. If the NeedIt application is not open in Studio from the last exercise, open it now.

a. In the main ServiceNow browser window use the Application Navigator to open System
Applications > Studio.
b. In the Load Application dialog, click the NeedIt application.

Register an event.

. In Studio, select the Create Application File button.

a. In the Filter… field enter the text Event OR select Server Development from the
categories in the left hand pane.

b. Select Event Registration in the middle pane as the file type then click
the Create button.

Configure the Event Registration:

Suffix: overdueNeedItTask

Event name: this field value is automatically populated

Table: NeedIt Task [x_<company_code>_needit_needit_task]

Fired by: Scheduled Script Execution - Find Overdue NeedIt Tasks

Description: This event is fired for each overdue NeedIt Task record

Click the Submit button to save the event in the Registry.

Modify the Scheduled Script Execution Script

In this part of the exercise you will modify the Find Overdue NeedIt Tasks Scheduled Script
Execution to generate the x_<company_code>_needit.overdueNeedItTask event for each
overdue NeedIt Task record.

1. If not still open from the last exercise, open the Find Overdue NeedIt Tasks Scheduled
Script Execution for editing in Studio. In the Application Explorer, click Server
Development > Scheduled Script Executions > Find Overdue NeedIt Tasks.

2. Edit the while loop script. Add this line to while loop:

gs.eventQueue('x_58872_needit.overdueNeedItTask',overdueNITasks,overdueNITasks.number,g
s.getUserName());

3. The while loop should look like this:

 4. Click the Update button to save the changes to the Scheduled Script Execution.

QUESTION: Which object is passed to the event generated by gs.eventQueue()? Why this object
and not current? If you aren’t sure, scroll to the Answers section at the bottom of this page.

Test the Event Generation

1. Force the Scheduled Script Execution to run by clicking the Execute Now button in the
Scheduled Script Execution form.

2. Switch to the main ServiceNow browser window and use the Application Navigator to
open System Logs > System Log > Application Logs.

3. Look for the Overdue NeedIt Task record messages. Do you see messages for the records
you expected? If you don’t see any messages, the Scheduled Job may not have finished
execution yet. To refresh the list, click the Additional Actions menu ( ) and select
the Refresh List menu item.

4. Look for the events in the Event Log.

a. Use the Application Navigator to open System Policy > Events > Event Log.

b. Use the Go to field to search for events with *needit in the Name field.

c. Examine the Parm1 field to verify the NeedIt Task records for the events are the same as
the NeedIt Task records from the Application Log. If not, debug and re-test.

Create a Script Action

In this part of the exercise you will create a Script Action to update the Priority to critical for all
overdue NeedIt Task records.

1. Register a Script Action.

a. In Studio, select the Create Application File button.

b. In the Filter… field enter the text Action OR select Server Development from the
categories in the left hand pane.

Select Script Action in the middle pane as the file type then click the Create button.

Configure the Script Action:

Name: Update Overdue NeedIt Task Priority

Event name: x_<company_code>_needit.overdueNeedItTask

Active: Selected (checked)

Copy this script and paste it into the Script field:

// Set the record priority to 1 - Critical

current.priority = 1;

// Update the record in the database

current.update();

Click the Submit button to save the Script Action.

QUESTION: If you look at the gs.eventQueue() method in the Scheduled Script Execution, the
overdueNITasks object is passed to the event. Why does the Script Action use the current object
and not the overdueNITasks object in the script? If you aren’t sure, scroll to the Answers section
at the bottom of this page.

Test the Script Action

1. Force the Scheduled Script Execution to run by clicking the Execute Now button in the
Scheduled Script Execution form.

2. You have already tested the Scheduled Script Execution and event generation so you
don’t need to test that again. Switch to the main ServiceNow browser window and use the
Application Navigator to open NeedIt > NeedIt Tasks.
 3. The overdue task records should now have a priority of 1 - Critical. You may have a
different number of overdue NeedIt Tasks records than shown here.

4. If the overdue NeedIt Tasks records are not critical, use the Event Log to verify the
events were generated. If they were, check the Script Action to make sure it is Active.
Verify the script has no errors. Test again.

Challenge

In this part of the exercise you will:

 Register an event, dueSoonNeedItTasks, for NeedIt Task records due in the next 24
hours.

 Modify the Find NeedIt Tasks Due Soon Scheduled Script Execution to generate the new
event for each record due soon.

 Create a Script Action, Update Due Soon NeedIt Task Priority, for the
dueSoonNeedItTasks event to set the NeedIt Task record Priority to 2 - High.

Use the work you have already done in this exercise as a model to register the
dueSoonNeedItTasks event, generate the event, and respond to the event.

When testing, make sure you have at least one NeedIt Task record due within the next 24 hours.

If you get stuck, see the Answers section at the bottom of this page for a possible solution.

Answers

Question: Which object is passed to the event generated by gs.eventQueue()? Why this object
and not current?

Answer: Scheduled Script Executions do not have access to the current object because they
trigger based on time and not on record accesses. In this script, the gs.eventQueue() method
generates an event for each overdue NeedIt Task record found by the GlideRecord query. The
overdueNITasks object is passed to the event as the script iterates through the while loop. Parm1
contains the record number. The record number appears in the Event Log in its resolved value.

Question: The gs.eventQueue() method in the Scheduled Script Execution passes the
overdueNITasks object to the event. Why does the Script Action use the current object and not
the overdueNITasks object in the script?

Answer: Script Actions always refer to the object passed by gs.eventQueue() as current.

Challenge: Event Registry

Find NeedIt Tasks Due Soon Scheduled Script Execution

Update Due Soon NeedIt Task Priority Script Action. Don’t forget to make the Script Action
active.

Using Custom Queues - Advanced Topic

If your application will create a large volume of events and/or the events take a long time to
process, you may choose to use a custom queue.

Define a custom queue by populating the Queue field for the event in the Event Registry. Use
only lowercase letters, no spaces, and no special characters except underscore (_).
Adding a value to the Queue field creates the custom queue. When the dueSoonNeedItTasks
event is generated, the event is added to my_queue. The events in my_queue are stuck in the
queue because there is no process watching the queue for events.

IMPORTANT: USE CAUTION WHEN FOLLOWING THESE STEPS.

DO NOT OVERWRITE THE text index events process SCHEDULED JOB.

To create a process to watch my_queue you will COPY the text index events process Scheduled
Job.

In the main ServiceNow browser window, use the Application Navigator to open System
Scheduler > Scheduled Jobs > Scheduled Jobs.

Locate the text index events process Scheduled Job and open the record for editing
Change the Schedule Item Name and the queue name in the Job context. The queue name passed
to GlideEventManager() must be an exact match to the queue name in the Event Registry.

DO NOT CLICK THE UPDATE button because that will overwrite the text index event process
Schedule Item. Instead, click the Additional Actions menu ( ) and select the Insert and
Stay menu item to make a new record.
The queue monitoring process you created will immediately look for and process events in the
my_queue event queue.

Using Custom Queues with gs.eventQueue()

After custom queues and a queue process are created, you can use the gs.eventQueue() method’s
optional fifth parameter to send events to the custom queue.

The overdueNeedItTask event does not have a custom queue defined in the event registry.

Use the fifth parameter to send the event to a custom queue. Enclose the queue name in either
single or double quote marks.
gs.eventQueue('x_58872_needit.overdueNeedItTask',overdueNITasks,overdueNITasks.number,g
s.getUserName(),'my_queue');

The gs.eventQueue() method sends the x_58872_needit.overdueNeedItTask event to the

my_queue custom queue.

Exercise: Save Your Scheduled Script Executions and Events Work (Optional)

In this module, you will save the work you have done in this module to your GitHub repository.

Commit Changes

1. If the NeedIt application is not open in Studio from the last exercise, open it now.

a. In the main ServiceNow browser window use the Application Navigator to open System
Applications > Studio.

b. In the Load Application dialog, click the NeedIt application.

Open the Source Control menu and select the Commit Changes menu item.
In the Commit Changes dialog, enter a Commit Message such as Scheduled Jobs and Events
Exercises Completed.

IMPORTANT: Although you will not see the Scheduled Script Executions in the local changes
list, they will be captured in the GitHub repository.

Click the Commit Changes button.

When the Commit Changes dialog reports success, click the Close Dialog button.
Scheduled Script Executions and Events Module Recap

Core concepts:

 Scheduled Script Executions are server-side script logic that execute periodically

 Daily

 Weekly

 Monthly

 Periodically

 Once

 On demand

 Use a Condition script to determine if the script in the Run this Script field should
execute

 Must end with a statement resolving to true or false

 Variables are also known to the Run this script field if JavaScript scope allows

 Scheduled Script Executions do not have access to current because they are not triggered
by record accesses or user interactions

 To execute a Scheduled Script Execution on the last day of the month, configure a Daily
Scheduled Script Execution to run on the 31st

 Use the System Scheduler > Scheduled Jobs > Today’s Scheduled Jobs module to see
what is on the schedule

 Events are an indication in ServiceNow that something notable has occurred

 Events can be generated by server-side scripts, workflows, ServiceNow processes, or by

user actions

 Events must be in the Event Registry for the ServiceNow processes to respond to events

 Pass the gs.eventQueue() method four parameters to generate events

 Event name

 GlideRecord object, typically current or record from a GlideRecord query

 Value that resolves to a string - parm1

  Value that resolves to a string - parm2

 Use the System Policy > Events > Event Log module to see which events have been
generated

 The Event Log displays the resolved values of parm1 and parm2 which is useful for
debugging

 Script Actions are server-side scripts which execute when events are generated

 Have access to event object

 The current object is whichever object was passed to the event by the
gs.eventQueue() method

 For events that are generated in high volume or if event processing takes a long time,
create custom queues