Re-opening Requests is bad, m’kay?

I’ve worked on Service Catalog engagements many times and have been often asked if it’s possible to configure the workflow to allow the re-opening RITMs or tasks after closure, with the possibility of somehow re-starting the workflow for that ticket. Of course, this is always possible, the ServiceNow platform is flexible enough to allow you to do whatever you want should you persevere hard enough. Is it a good idea though? In almost all circumstances no, principally because of the nature and intention of Service requests to be a linear and repeatable fulfilment that can be easily defined by distinct approval stages and actions by specific people. By allowing items to be re-opened you’re negating the value of the pre-agreed delivery time for a specific catalog item, as there may now be grey areas in the process whereby the user needs to provide more information, or another piece of work needs to be done by another team that was not included in the original workflow. It will also make reporting more difficult on those items, as how can you now give an accurate measure on how much time teams spending (or saving) on request fulfilment if they are now being re-opened and assigned to other people?

Of course, there are many arguments as to why the process may need to be extended to allow the re-opening of tickets, but in my experience most of these reasons should be handled by Incident Management. In cases were a request needs to go back to the user for more information, the easiest technical solution to this would be to close the ticket and force the user to raise another. Great user experience, right? That person needs to now go back to the Service Catalog and re-key that item and submit with a minor amendment to include the missing information. If we could somehow mandate that requirement to re-submit should the relevant information not be included, but not require the user to re-key everything, we could potentially have the best of both worlds. I’ve worked on and provided here a solution that caters for just that use case, and this diatribe is my demonstration of how you could implement it on your own instance.

Overview
This example works on the basis that a requestor will receive an email notifying them that the approver has rejected the requested item, with a comment from that approver as to why it was rejected. The email notification has been modified to include a link that will take the user back into ServiceNow and allow them to re-submit the form. What the user doesn’t see is that link now contains the rejected RITM number as a URL parameter, and when clicked the magic of ServiceNow GlideAjax will pull the variable responses into the new Catalog Item form so that the user can re-submit without having to completely fill in what could be a very long form.

How to Implement
Download Update Set
First thing you’ll need to do is download and import this update set into your instance. After downloading the XML, simply right-click on any list to bring up the context menu, then select ‘Import XML’. From here navigate to the downloaded XML file and install. Following this, remember to navigate to the ‘Retrieved Update Sets’ dialog and preview then commit the new update set.

Update Email Notifications
This code can then be applied to any catalog item in your instance very easily. However, you’ll first need to update the “Approval Rejected” email notification to add the customised link mail script to the notification body by adding this line:

${mail_script:dmns.ritm_requestor_resubmit_link}

Add Variable Set
From here, the client script will need to be added to each Catalog Item that requires this functionality. Simply navigate to the Catalog Item of choice via the ‘Maintain Items’ module, navigate to the Variable Sets related list, click Edit and add the ‘DMNS Get reject RITM vars’ to the list of selected variable sets.

Now, when a requestor receives a notification on rejection of an RITM, the link will be displayed and clicking on that link will take them back to the form. Should that Catalog Item contain the variable set above, the variable values will be copied over from the rejected item.

Please feel free to play around with this and leave questions in the comments below should you have any!

Leave a Reply

Your email address will not be published. Required fields are marked *