In the ServiceNow Human Resources suite of plugins, the Human Resource: Lifecycle Events plugin includes an additional automation engine for managing HR Service workflows for cases that have a defined sequence of activities, spanning a prolonged period of time. Think of onboarding, maternity leave, and performance improvement plans as typical examples of Lifecycle Events.

Activities that should be triggered at a particular point in the Lifecycle Event process are grouped together into Activity Sets.

In ServiceNow, we can define the condition for when an activity set should be triggered within the Lifecycle Event, and here is where we find a limitation within the automation engine.

The Limitation: A Four-Hour Wait

There are six types of triggers for a lifecycle event, which are:

• Immediate – The activity set is triggered as soon as the case is in the “Ready” state.
• Date – The activity set is triggered on a particular date, usually offset by a date related to the “Employee Start Date”.
• Other activity sets – The activity set is triggered by the completion of other dependent activity sets.
• Advanced – The activity set is triggered by evaluating the outcome of a script with either a “true” or “false” value returned.
• Condition – The activity set is triggered based on a condition defined on the related case table.
• Combination – The activity is triggered by a combination of conditions that need to evaluate as true (Date, Other Activity Sets, Condition).

Other than the “Immediate” and “Other activity sets” trigger conditions which evaluate in real-time, the rest are re-evaluated on a default interval wait time of four hours, which can delay processes unnecessarily.

This default setting means that any updates or conditions met during this interval will not trigger the next step until the time elapses, which is not always ideal for time-sensitive operations.

Reducing the Evaluation Interval Default Wait Time

One solution is to reduce the time interval between Activity Set trigger conditions being re-evaluated to something more appropriate.

As defined in the ServiceNow Docs, the default evaluation interval can be modified by navigating to the Dictionary Entry (sys_dictionary) table and finding the “evaluation_interval” column for the Activity Set table.

CAUTION: This is a global value and updating the value will update the evaluation interval for all Lifecycle Events. Performance considerations have to be made when reducing the evaluation interval. As mentioned in the ServiceNow Docs:

In addition, although reducing the time interval may reduce the time waiting for an Activity Set to trigger, there will still be a delay. A more optimal solution would be real-time re-evaluation.

An Alternative Solution

ServiceNow provides guidance on an alternative method for triggering Activity Sets more frequently in their Docs which describes a server-side script that broadcasts the “check_activity_set_trigger” event to all Lifecycle Event workflows:

(function executeRule(current, previous /*null when async*/) {
	var wf = new global.Workflow().getRunningFlows(current);
	while (wf.next()) {
		if (wf.getValue('name') !== 'HR Activity Set Trigger Check')
			continue;
		new global.Workflow().broadcastEvent(wf.sys_id, 'check_activity_set_trigger');
	}
})(current, previous);

Scheduled Jobs and Advanced Business Rules are some of the recommendations from ServiceNow for triggering this script. However, I have some reservations about both of these options for the following reasons:

• Scheduled Job – Given the script will be triggered on a regular schedule this is essentially no different from modifying the “evaluation_interval” value. It is not real-time.
• Advanced Business Rule – On the face of it, this has the possibility to be real-time but there are some short comings:
  • 1 – In order to make the business rule generic enough to cater for all possible Activity Set trigger conditions, the business rule would have to broadcast the check_activity_set_trigger event for all case updates which may have a performance impact.
  • 2 – Trigger conditions that are defined on dot-walked values, i.e., values that live on different records, would not trigger the business rule – not real-time for this scenario.

In my opinion a UI Action that is triggered manually by a HR Agent, broadcasting the check_activity_set_trigger event, is the preferred option for the following reasons:

• Gives the HR Agent near-real-time evaluation (including dot-walked fields)
• Reduces performance impact as running on-demand vs. each record update/small interval period.

The Optimal Solution

There is however, still one limitation with this solution, and that is that the script triggers the check_activity_set_trigger event to all active Lifecycle Events on the platform.

To address this shortcoming, we can modify the existing script from the ServiceNow documentation to only send the event for workflows related to the current case and therefore enhance performance.

Script Breakdown:

The script works in two parts:

Save the record

• Save the record so that the database is updated with the latest value
• Confirm the update isn’t aborted (i.e. missing mandatory fields)
• Redirect the URL back to the case form

Find all ‘HR Activity Set Trigger Check’ workflows related just to the current record

• Query the Workflow Context table (wf_context)
• Find all instances of the “HR Activity Set Trigger Check” that relate to the current case
• Broadcast the event 'check_activity_set_trigger' event to each of those workflows

(function executeRule(current, previous /*null when async*/) {
    current.update();
    if (!current.isActionAborted()) {
        action.setRedirectURL(current);
        // Find all 'HR Activity Set Trigger Check' workflows related just to the current record
        var wfContextGR = new GlideRecord('wf_context');
        wfContextGR.addQuery('table', current.sys_class_name);
        wfContextGR.addQuery('id', current.sys_id);
        wfContextGR.addQuery('workflow_version.name', 'HR Activity Set Trigger Check');
        wfContextGR.query();
        // Send event to each of these workflows
        while (wfContextGR.next()) {
            new global.Workflow().broadcastEvent(wfContextGR.sys_id, 'check_activity_set_trigger');
        }
    }
})(current, previous);

This script ensures that only relevant workflows linked to the current case receive the trigger event, thus minimizing unnecessary processing and improving the system’s performance.

Additional configurations for the UI Action:

• Name = Re-evaluate Lifecycle Event
• Order = 450 (After state buttons but before cancel and delete)
• Form Button = true
• Client = false (Server side script)
• Show on Update = true
• Condition = current.active == true && current.state!=1 && current.state!=24 && current.state!=11 && current.state!=20 && current.hr_service.fulfillment_type== 'lifecycle_event'
  • i.e. The case is active
  • The state of the case is not Draft, Awaiting Approval, Awaiting Acceptance, or Suspended
  • HR Service is categorized under the fulfilment type “Lifecycle Event”

Conclusion

By implementing this tailored solution, you can enhance the performance of Lifecycle Events, enabling faster and more efficient workflow management. This approach not only optimizes resource utilization but also ensures that critical HR processes are as responsive as necessary.