Event Management – delay alert action rule processing

By default ServiceNow processes the alert action rules directly when the alert is created. This can create false incidents if you already have remediation tasks implemented which fire, when an alert is raised (one example is automatic recovery actions in SCOM).

To avoid that you can create a system property, which will generally delay the process of the alert action rules. With that solution you handle all alerts in the same way and you cannot have exceptions.

How to implement:

  • Enter sys_properties.list in the filter navigator and press Enter.
  • Click the New button.
  • Name the new property¬†evt_mgmt.alert_rule_delay, select Type integer and enter a value in seconds.evt_mgmt.alert_rule_delay
    Here you can see, I have entered 360 for 6 minutes.

Why did I select 6 min? The reason is that the SCOM connector by default checks every 2 min. Most of the SCOM rules run every 5 min. With 6 min delay most of the short outages should not create Incidents.

The result is this:


You can see that the task is created 6 min after the original alert.

Attention: This system property is tested in the Jakarta release. I cannot guarantee, that it works in other releases or will be replaced by new functionality in newer releases.


Workflow inputs

What is a workflow input?

A workflow input is a string variable, which can be defined within a child workflow and to transfer data from a parent workflow.

When do I need a workflow input?

An input can be necessary, if a value, which was created within the parent workflow, needs to be used within the sub workflow and no existing form field could be used to write that value to.

Workflow inputs are only available in workflows which are not used for Catalog items (using the table Requested Item = sc_req_item). Catalog item workflows use variables defined in the form and do not display the inputs tab in the workflow properties.


As I struggled with the documentation from ServiceNow about these input variables, I wanted share an example how I used an input.

I have two workflows:

  1. Parent: Change Request – System Build
  2. Child: Change Request – System Build Tasks

I have no field in the change request, where the device name is entered separately, therefore I had to extract it from the description.

I have used the scratchpad to store the extracted value.


Now I have the name of the device in the scratchpad variable devicename of the parent workflow (Change Request – System Build).

As scratchpad variables are only available in the context of the workflow it is running in, I cannot use this variable in the subflow. Now I need to have an input variable in the subflow.

I checkout the subflow (Change Request – System Build Tasks), went to Properties > Edit Inputs and created this input:

When I now open the subflow activity in the parent workflow (where I call the subflow), then the devicename_task field is shown.


I give the value from the scratchpad variable to this input variable of the subflow by entering ${workflow.scratchpad.devicename}.

Within the subflow I then can get the value of the input variable with this command:
(Attention! it is the column name, I need to use!)

That’s it.

Here is also a good summary about variables in a workflow.


Workflow – Check Blackout Conflict

During our Change Management implementation in ServiceNow we realized that we need to change the Change Request – Normal workflow to check if the change is scheduled during Blackout. If that is the case, we wanted to have one additional approval.

As there was no default option to check for the Blackout conflict, we used this script to get a ‘yes’ or ‘no’ answer within the IF activity.

var count = new GlideAggregate('conflict');
var conflicts = 0;
conflicts = count.getAggregate('COUNT');

answer = ifScript();

function ifScript() {
if (conflicts>0) {
return (‘yes’);
return (‘no’);