- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-29-2020 12:08 PM
I have a task on a workflow which will disable monitoring for a CI at a set appointment time. This works for a straight flow, however I'm trying to capture edge cases where the original appointment time needs to be changed.
I've added an option to catch a time update on the Request Item, which triggers an event, and this works.
I'm having two problems:
1. Completion of one of the timers and execution of the script task doesn't cancel the other branch, since a Join wasn't used to bring both of these branches together I thought that the first one to reach the script would cancel the other. You can see in the attached screenshot the "wait for event" is still running, even though the subsequent "Run Script" action has already executed. Maybe the Join later in the flow is impacting this, but I don't understand why it would.
2. The event trigger upon appointment change will work once, but how can I ensure that subsequent changes to the appointment time will also be caught, and update the timer with the new time selected.
Very much appreciate any tips and insights if someone else has run through a similar scenario.
Solved! Go to Solution.
- Labels:
-
Scripting and Coding

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-29-2020 05:23 PM
Well...
When a workflow timer activity is triggered, the result is that a scheduled job is created in the sys_trigger table. The challenge is finding the right entry to update - but it can be done.
I am assuming that your business rule runs against the sc_req_item table. For this example, I'll also assume that the variable on the RITM that you are using in the timer is called appointment_time.
The following should give you what you are looking for.
Business Rule: Advanced, runs before, on update.
Condition is item = your catalog item.
Script:
(function executeRule(current, previous /*null when async*/) {
//First, we have to get the context for the workflow running against current.
var context = '';
var wf = new GlideRecord('wf_context');
wf.addQuery('id', current.sys_id);
wf.query();
while(wf.next()) {
context = wf.getValue('sys_id');
}
//this is the name of your timer activity in the worklow - since you can have more than one.
var timer_name = 'This is my timer!';
var doc_id = '';
//Now we have to get the executing workflow activity records associated to the context.
var wf_executing = new GlideRecord('wf_executing');
wf_executing.addQuery('context', context);
wf_executing.query();
//Now we cycle through the activities to find the one we have named.
while(wf_executing.next()){
if(wf_executing.activity.name == timer_name) {
doc_id = wf_executing.getValue('sys_id');
}
}
//Now, we use everything we have learned to find the right entry in the scheduled job table.
var schedule = new GlideRecord('sys_trigger');
schedule.addQuery('document_key', doc_id );
schedule.query();
while(schedule.next()) {
//and here comes the magic
//update the next_action field using the value in the appointment_time variable.
schedule.next_action = current.variables.appointment_time;
schedule.update();
}
//Success!
})(current, previous);
If this was helpful, or correct, please be kind and remember to mark appropriately!
Michael Jones - Cloudpires
Michael D. Jones
Proud member of the GlideFast Consulting Team!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-29-2020 05:23 PM
Well...
When a workflow timer activity is triggered, the result is that a scheduled job is created in the sys_trigger table. The challenge is finding the right entry to update - but it can be done.
I am assuming that your business rule runs against the sc_req_item table. For this example, I'll also assume that the variable on the RITM that you are using in the timer is called appointment_time.
The following should give you what you are looking for.
Business Rule: Advanced, runs before, on update.
Condition is item = your catalog item.
Script:
(function executeRule(current, previous /*null when async*/) {
//First, we have to get the context for the workflow running against current.
var context = '';
var wf = new GlideRecord('wf_context');
wf.addQuery('id', current.sys_id);
wf.query();
while(wf.next()) {
context = wf.getValue('sys_id');
}
//this is the name of your timer activity in the worklow - since you can have more than one.
var timer_name = 'This is my timer!';
var doc_id = '';
//Now we have to get the executing workflow activity records associated to the context.
var wf_executing = new GlideRecord('wf_executing');
wf_executing.addQuery('context', context);
wf_executing.query();
//Now we cycle through the activities to find the one we have named.
while(wf_executing.next()){
if(wf_executing.activity.name == timer_name) {
doc_id = wf_executing.getValue('sys_id');
}
}
//Now, we use everything we have learned to find the right entry in the scheduled job table.
var schedule = new GlideRecord('sys_trigger');
schedule.addQuery('document_key', doc_id );
schedule.query();
while(schedule.next()) {
//and here comes the magic
//update the next_action field using the value in the appointment_time variable.
schedule.next_action = current.variables.appointment_time;
schedule.update();
}
//Success!
})(current, previous);
If this was helpful, or correct, please be kind and remember to mark appropriately!
Michael Jones - Cloudpires
Michael D. Jones
Proud member of the GlideFast Consulting Team!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-30-2020 12:40 PM
Michael, this is a great approach. I was trying to catch the appointment time change in my workflow, but this method will allow the workflow to continue on after creating the initial timer and any changes will just be dealt with separately on the back end as often as the appointment needs to be updated.
I'm going to implement this and do some testing and let you know how it goes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-02-2020 12:56 PM
Worked like a charm Michael, thank you very much.
This also helped me solve a problem I didn't realize I had, where if the RITM was canceled the trigger item is still sitting around, and would proceed to disable monitoring for the device at the last appointment time entered before cancellation.
I'm able to use this same script to delete the underlying trigger item entirely.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-02-2020 02:57 PM
Glad I could help!
Michael D. Jones
Proud member of the GlideFast Consulting Team!