Reset change request workflow, approvals, and tasks

When implementing the Change management process in ServiceNow you’ll probably encounter a scenario where your entire change workflow (including all tasks and approvals) needs to be reset.  The first option to consider (assuming you’re using the graphical workflow engine to manage the tasks and approvals) is the Rollback workflow activity.  The rollback activity works great for a lot of scenarios, but what if you don’t have a defined point in the workflow where everything should be rolled back?  What if the rollback (or reset) can happen at any point in time?  There’s not really an easy way to handle this within the workflow itself since you would need to check for a rollback condition at an infinite number of places.

I recently encountered this scenario while working with a client and used the ‘SNC Approval – Reset conditions‘ business rule to solve the problem.  By using a business rule, you can allow the end user (which in this case would typically be a member of the Change Advisory Board) to indicate when a full workflow reset should be done.  Users can force a reset by setting the value of a field on the Change request ticket itself. The ‘SNC Approval – Reset conditions’ business rule gives you 3 different options for how the approval reset should happen.

1 – Cancel all existing approvals and reset
2 – Delete all existing approvals and reset
3 – Leave all existing approvals alone and reset

I chose to use option 1 so that we would have a record of any previous approval activity that had taken place. Depending on the situation and your organization’s audit requirements, option 2 might be a good alternative as well. I can’t think of a scenario where option 3 would be a good thing but it’s there if you need it.

The solution I used was to set up a UI action button that I named ‘Reset change workflow’.  The sole purpose of the UI action is to set some value on the change request ticket to trigger the ‘SNC Approval – Reset conditions’ business rule.  I chose to create a new choice value in the ‘Approval’ field called ‘Reset’.  My business rule checks before any update to see if the value of the ‘Approval’ field is ‘Reset’.  If it is, then the workflow attached to the change request gets reset.  Here’s the step-by-step guide to implement this type of reset functionality…

1Personalize the choices for the ‘Approval’ field on the change request form and add an option called ‘Reset’.

2Create a new UI action with the following parameters:

Name: Reset change workflow
Table: Change request
Client: True
OnClick: setApprovalReset()
Condition: gs.hasRole(‘itil’)
Form button: True
Script:

function setApprovalReset(){
var con = confirm('Performing this action will reset the associated workflow including all approvals. Are you sure you want to continue?');
if(con){
g_form.setValue('approval', 'Reset');
gsftSubmit(gel('sysverb_update_and_stay'));
}
else{
return con;
}
}

3Modify the ‘SNC Approval – Reset conditions’ business rule as follows:

Name: SNC Approval – Reset conditions
Table: Change request
Active: True
Condition: current.approval.changesTo(‘Reset’) && gs.hasRole(‘itil’)
Script:

// these are the conditions under which the change request approvals need to be canceled and reset
// steps to activate
// 1. enable this business rule
// 2. add some comments so the reset will be noted in the approval history
// 3. uncomment the code for restart or reset based on your requirements
// 4. define the reset condition in checkResetConditions function below
// 5. you must set doReset once you capture the change(s) you are interested in

var comment = 'Approval reset by ' + gs.getUserDisplayName(); //written to the approval_history
if (checkResetConditions()) {
// create a global variable lock on the current record
// this will prevent triggering a second reset while the first reset is still in progress
// lock will be release in a late running business rule called 'Workflow Release Lock'
if (typeof GlideRecordLock != 'undefined')
chg_wf_lock = GlideRecordLock(current);
else
chg_wf_lock = new Packages.com.glide.script.RecordLock(current);
chg_wf_lock.setSpinWait(50); //wait for lock
if (chg_wf_lock.get()) {
gs.print('SNC Approval conditions business rule is locking the ' + current.getDisplayValue() + ' during the workflow reset');

// The following options are available for resetting the approvals:
//
// 1. Mark all existing approvals for the change as 'cancelled' and restart the workflow to create new approvals
new WorkflowApprovalUtils().cancelAll(current, comment);
new Workflow().restartWorkflow(current);
//
// 2. Delete all of the existing approvals for the change and restart the workflow to create new approvals
// new WorkflowApprovalUtils().reset(current, comment);
// gs.addInfoMessage('Workflow has been reset since key fields have been modified');
//
// 3. Leave the approvals for the change in their current state and restart the workflow.
// (so that any new approvals that are required will be created)
// if (comment)
// current.setDisplayValue('approval_history', comment);
// new Workflow().restartWorkflow(current, true);
//

}

//Use this section to reset any necessary information on the Change request
current.work_notes = 'Change approvals and workflow reset due to material change by ' + gs.getUserDisplayName();
current.approval = 'not requested';

//Use this section to reset any necessary information on any associated Change tasks
var tsk = new GlideRecord('change_task');
tsk.addQuery('change_request', current.sys_id);
tsk.query();
while(tsk.next()){
tsk.work_notes = 'Change request workflow reset.';
tsk.update();
}
gs.addInfoMessage('Change approvals and workflow reset for ' + current.number + '.');
}

function checkResetConditions() {
var doReset = false; //default to no reset
//add reset conditions here such as:
//if (current.assigned_to.changes())
doReset = true; //enable the reset

return doReset;
}

Date Posted:

December 28, 2009

Share This:

23 Comments

  1. alli December 29, 2009 at 12:30 am

    seems, all of your posts are connected to my open tickets in the hi server :)

    cheers

  2. John May 12, 2011 at 1:55 am

    I need to be able to reset approvals on a non-change mgmt workflow. Can I simply duplicate this process, specifying the table on which the workflow runs?

    • Mark Stanger May 12, 2011 at 6:25 am

      Pretty close. The ‘change_task’ section towards the bottom of the ‘SNC Approval – Reset conditions’ business rule would need to be modified since it’s change-specific, but the rest should be identical.

  3. Chris June 27, 2011 at 1:24 pm

    Thanks this is great information. Wanted to mention the link in 2nd paragraph for ‘SNC Approval – Reset conditions‘ appears to be broken. You did include the script later on but thought it was worth mentioning.

    Cheers and thanks for another great article!

    • Mark Stanger June 27, 2011 at 3:07 pm

      Thank you! Looks like the wiki article changed a bit. I’ve fixed the link to point to the new location.

  4. Michael S July 1, 2011 at 7:56 am

    Excellent ideas here. Thanks so much for the contribution Mark. I am a newbie to this community, so my apoligies for any stupid questions.

    Will this reset approach work when the reason why the change record needs to be reset is that the wrong change workflow was selected.

    Let me explain. Impact and Risk are used to automatically set the our change workflow. We have 3 change workflows. Routine, Standard and Emergency. Depending on the Impact and Risk choice, one of these 3 workflows are set. What happens is that after the change is submitted and the workflow is kicked off, someone re-evaluates the impact and risk and they want to change it. Thus changing the workflow from say like standard to routine.

    I have experimented with using the setApprovalReset function approach but I can’t get it to reset and use a different workflow. So is it possible or do I need to go in a different direct altogether?

    • Mark Stanger July 2, 2011 at 2:00 pm

      Hey Michael,
      I don’t mind stupid questions as long as you’re okay with stupid answers :). This is a good question though. I think you’ll want to go in a little bit different direction on this. You probably want to cancel the entire workflow and then set up your other workflows so that they will bind when the conditions change. You can find some examples here…
      https://servicenowguru.com/scripting/business-rules-scripting/canceling-executing-workflows-task-closure/

      • Antonio G January 17, 2013 at 6:24 am

        Mark, your link appears to be broken. My problem is similar to Michael’s and it seems like this would be helpful!

        • Mark Stanger January 17, 2013 at 6:34 am

          Thanks for the heads up! I’ve fixed the link in my response to Michael.

      • Monette February 26, 2014 at 6:34 pm

        Hi Mark,

        I find that the approvals are being reset, but the tasks are not reset. When the approvals are approved, nothing changes in the tasks. I tried to mark one task as ‘Closed Complete’, but it didn’t trigger the workflow. When I checked the workflow status using “show workflow”, I saw that it considered it to have run having the result of ‘1’. The state or result before the workflow got cancelled.

        I tried to cancel the workflow first before restarting, but it still is not working. Here’s an excerpt of my code:
        new Workflow().cancel(current);
        new WorkflowApprovalUtils().reset(current, comment);
        new Workflow().restartWorkflow(current, false);

        Do you know what I could change?

        Many thanks,
        Monette

        • Mark Stanger February 27, 2014 at 7:10 am

          There’s a lot of code here, but the only part that is relevant to what you are struggling with is the ServiceNow-provided code in these two lines…

          new WorkflowApprovalUtils().cancelAll(current, comment);
          new Workflow().restartWorkflow(current);

          I would try to reduce the business rule down to those two lines and see what happens. If that doesn’t solve the issue, then I would try it in a ServiceNow demo instance to see. I’m guessing you’ve got some other business rule or workflow activity/script interfering with this script.

  5. Catherine Crigger December 8, 2011 at 8:01 pm

    Hi Mark,

    I have followed your instructions here for setting up this Reset Change Workflow and have run into a couple of snags.

    1. The Reset Change Workflow button now appears on the Change Form, but what I would like to do is limit it to be seen by only a specific GROUP of users. Can you help me with what changes I need to make.

    2. When I copied the script I am getting this error
    JavaScript parse error at line (1) column (28) problem = illegal character

    Can you point me in the right direction on how to fix this?

    Thank you for your help.

    Catherine

    • Mark Stanger December 8, 2011 at 8:10 pm

      Hey Catherine. You can set the ‘Condition’ field on the UI action to restrict access. You can restrict access to a particular group by using a line like this for the condition…

      gs.getUser().isMemberOf('YOUR_GROUP_NAME_HERE');
      

      As for the javascript error, it’s probably caused by copying the code and trying to paste it directly into a script field with the syntax highlighter on. You should temporarily disable the syntax highlighter for the script field by clicking on the button next to the script field label, then paste the code in. That should prevent you from seeing these types of errors when you copy/paste code from the web. Another method would be to copy the code and paste first into notepad or something similar to strip the web formatting.

  6. Catherine Crigger December 8, 2011 at 9:01 pm

    Mark,

    Just to be a little bit more clear on the JavaScript Error it is actually in this condition

    current.approval.changesTo(‘Reset’) && gs.hasRole(‘itil’)

    Any ideas where I should look?

    Thanks
    Catherine

    • Mark Stanger December 9, 2011 at 5:50 am

      Simplest way to find out is just to remove each piece of the condition until the error goes away, then you’ll know what part contains the error. My best guess is that it’s still a copy/paste error. Since it’s small, you might just try typing the condition directly and see if that helps.

  7. David Martin December 13, 2011 at 10:05 am

    Hi Mark

    I have used this numerous times, mainly using scenario 1, however on this occasion I need the reset to reset the workflow but not create any approvals straight away. I want them to be created when they go through the workflow again.

    Any ideas how I could achieve this, I do not want to delete them, just keep them, probably cancel them or keep the states as they are.

    Thanks
    Dave

    • Mark Stanger December 13, 2011 at 10:43 am

      Hey Dave,

      I think for that scenario it might be more effective just to use the standard workflow rollback activity. The way to handle that in the workflow is to set up a ‘Wait for’ workflow activity, followed by a rollback, that spans the entire duration that a rollback could potentially occur. The ‘Wait for’ could wait for a specific state that would be set by your UI action.

  8. David Martin December 14, 2011 at 8:53 am

    Thanks Mark, I have multiple points of when the workflow could be reset, so was hoping to have just 1. Thinking about it, in this situation it may be better to use the rollback functionality.

    Cheers
    Dave

  9. Amruta May 27, 2013 at 7:21 am

    Hi Mark

    This solution works if all approvals have to be reset and workflow has to be restarted. However, if there is a requirement that workflow should be reset to a specific task state and approvals after that task state should only be reset – how can this be handled? If the condition on which this reset should happen could have been easy, we could have used rollback activitiy or goto activity in workflow editor. I do not see any script functions for rollback on wiki. Any ideas?

  10. Joe S October 23, 2013 at 9:11 am

    Hi Mark,

    We’re having an issue getting this functionality to work in Calgary. When clicking the button now the action will reset the approval to reset but nothing is happening to the approval tasks, change tasks, and the actual workflow. Has anyone else been having a problem with this function in Calgary?

    • Joe S October 23, 2013 at 10:22 am

      Hi Mark,

      We’ve figured out our issue just not sure why it happened. The business rule didn’t exist on our instances running Calgary. We found the wiki article detailing the business rule and the API call changes in Calgary. We copied the business rule from our QA instance that wasn’t running calgary made the changes to the package call and all is working now. Just not quite sure why the business rule would have been deleted or not copied in the upgrade process.

      • Monette February 26, 2014 at 6:28 pm

        Hi Joe,

        We are running Calgary also and find that only approvals are reset but not the tasks. May I know which business rules and other script includes you found to not be in calgary, please?

        Cheers,
        Monette

  11. Chenelle Tucker April 15, 2014 at 2:45 pm

    Hi everyone,

    I have a different issue here. I have a workflow with process approvals and also out of the box approvals, or shall I say manual group approvals to be added. However when we add a group to the group approval tab and set it to “wait for: Anyone to approve” when we go in and test it by approving on of the users in the approvers tab, its approved, but the other members in the group does not change to “No longer required” We have a business rule on it but it isnt working, Anyone ran into this using the changemangement process in the Calgary release? We have workflow group approvals and the “Wait for anyone to approve” works, but not for the manual group approvals. Please advise if anyone can. Thanks!

Comments are closed.

Categories

Tags

Loading

Fresh Content
Direct to Your Inbox

Just add your email and hit subscribe to stay informed.