Cancelling and Restarting a Single Workflow

[chaslage]

The current issue I am having is a task record, Service Request, that has multiple Workflows running against it.   One of those workflows is an email reminder that the user can set to remind them to follow up with the user, this could be a date as far in the future as they want.   A very simple workflow, but for the few issues:

- If they decide to change the date in mid workflow then the workflow needs to restart.

- If they decide to just blank out the field then we need to cancel that workflow.

- If the workflow completes and they decide they need another reminder on the same record, it won't run a second workflow since the first one completed.

Right now I am batting a 0 on this since what I tried to get the contexts and get an "undefined", even though there is a completed Workflow.

See: http://wiki.servicenow.com/index.php?title=Workflow_Script#getContexts.28record.29

Maybe I am barking up the wrong tree?   Any thoughts?

Thanks!

[eican]

First you could check the workflow context table manually for all context records of your task the workflow is running for to troubleshoot why getContexts is returning undefined. Normally the function takes the current GlideRecord object and return the contexts for it.

In regards to the main problem, resetting an existing timer, I am also thinking about how to tackle this but currently it's not pressing so didn't 't decide on a solution.

However, maybe creating a scheduled job via script solves this ?

Maybe disconnecting this part completely from the workflow is a way to address it. That way you could offer the users a UI Action with which they could restart or create new timer events.

[chaslage]

I do see this as a nice option, though the issue is I am not 100% sure how I can trigger a notification that is unique based on the record (sc_request) asking for it.

Here is the desired solution if I use this option:

Someone fills in the blank, this will create a scheduled notification that will remind them to check up on this Service Request.   If someone blanks out the date on the request then it will deactivate the request.   Someone changes the date before the scheduled item runs, it will deactivate and create a new schedule for that.

I see the best option is to create a manual script for each job that references the originating request.   Any ideas?

Thanks!

[scwillson]

I have a very similar situation. and have yet to find a good solution. I've been trying to work out a solution that can be applied to both the Incident and the Requested Item tables. I currently have workflows on each table for the purposes of pausing the SLA clock while the INC or Task are in pending. Then resuming when the 'due_date' field has waited for the full duration (i.e. has met it's due date).

The part of the issue you described that I am also dealing with is when the 'due date' is changed on the form after is it already set in the WF, the timer will not come out until the original timer expires. I've had some helpful suggestions regarding creating a script to update the 'sys_trigger' table, but wan't able to get it working yet.

I've since taken a different approach to the problem by simplifying the WF. It now just branches to the due_date timer and a 'wait for WF event' action, simultaneously. While the WF waits in that state, I have a BR setup to look for if the 'due_date' changes. If it does, it triggers the WF event, which then ends the WF.

The problem I have now is that the WF doesn't kick back to the start even though it meets the starting conditions of the WF. I've now started looking at adding a script action that would restart the WF after the event is triggered.

I am aware this is by no means a solution, but I am hoping that we can perhaps reach a solution through discussion.

[PeterWiles]

I did my followup reminder with a delayed event instead of a workflow. I created a BR that checked for a change on my followup date which fired the below:

if(!current.follow_up.changesFrom(""))

{

var event = new GlideRecord("sysevent");

event.addQuery("instance", current.sys_id);

event.addQuery("name", "incident.reminder");

event.addQuery("processed", "");

event.query();

while(event.next())

{

        event.state = "error";

        event.update();

}

}

if(current.follow_up != "")

{

        gs.eventQueueScheduled("incident.reminder", current, gs.getUserID(), gs.getUserName(), current.follow_up);

}

The above puts in an event at the followup time and if the date changes or gets cleared, it cancels the event, before creating a new one if needed.

I don't know if it will meet all your requirements/processes but it works for me.

Pete