Catalog item rejection rollback

[Blair5]

When an approver rejects an item, the entire request is closed. We would like to allow for the item to go back to the submitter instead of closing the ticket.
We have about 30 catalog items that have approvals and I have tried this out on one catalog request so far. The things that will cause issues are the variables. I have all variables set to admin write access at the variable level. They are all read only when a submitter views the item. I started to open them up and will have to write a client script to make them read only again at the task level.
Has anyone else done this for catalog items? Could anyone recommend a better way?

[khabibulan72]

If I understand you correctly, you want the rejected request to go back to the person who submitted it. This is possible, but there are some obvious issues. First, once the catalog item is submitted it creates a request and request item. These records can appear in the "My Tickets" queue of the requester, but they generally do not contain all of the variables that were on the original catalog item. If the requester is an ESS user and not a process user, there's also a very limited amount of options they have for updating the ticket. It can be done, but you'll have to put some kind of a flag on the form that they click when they have updated the necessary information (allowing that those fields can be added to the RITM in the first place), then a "wait for" condition needs to be in the workflow to trigger that the process is ready to continue. From an ITIL standpoint, a service request is a pretty straight-forward transaction with few or now controls needed. This is generally why most customers close out the rejected request and send a notification to the requester with the rejection comments and the instructions to resubmit if necessary.

[Blair5]

Mike,

You understand me correctly. I actually did do what you're suggesting on one of our workflows. I added a roll back and a wait for condition. When the Request Item is in the hands of the submitter, there is a button called 'Return for approval' that triggers the workflow. The problems are

- we locked down all variables to be writable to the admin which we'll have to reverse
- there are ~40 workflows that have approval that will need to be updated
- the RITM looks nothing like the request form that was submitted by the submitter

I appreciate your feedback and will discuss with my team. We like to adhere to the ITIL standard, so this may not be the way to go.

Thank you.

[Aaron40]

I have to agree with khabibulan72, the standard practice would be to notify the creator and let them know their request was cancelled and they need to resubmit a new one. It'd be possible to create a new Request state to put the request into upon cancellation but you'll end up having issues with the workflows and the RITMs that were attached to the original REQ.

Also, there must have beeen some modifications because a cancelled/unapproved RITM shouldn't close out a REQ unless it's the only RITM in the REQ.

[khabibulan72]

Hi Blair - thanks for the follow-up information. You might be able to get done what you need by using a dedicated view for the specific type of sc_task record involved. That way an ACL could be used to allow the submitted_by/requested_for to make modifications. Good luck either way!