Resolve On-Hold Linked Requests

[CraigP]

A colleague has noticed that the "resolve linked requests" option isn't available for linked requests that are on-hold.

Is there a system setting to allow this to be possible? Alternatively is there an easy way within the Service Manager UI to find all requests linked to a request and change their status to open?

[Martyn Houghton]

@CraigP

A request needs to come off hold for the timers to be restarted so that when you resolve it the timers have already recalculated the Respond By/Resolve By values, else you will get incorrect SLA performance values.

You can do a bulk Update on requests under the same service from the Request List view, but it will depend on what BPM suspect node you have in your workflow as to whether this will then unpause the request. 

Cheers

Martyn

 

[James Ainsworth]

Hi @CraigP

You  can control what actions are available on requests from within the Service Manager Configuration.  Hope this helps.

 

[CraigP]

I tried enabling the "Resolve" option under the "On Hold settings" but this does not seem to impact the ability to resolve linked requests that are on-hold.

I've taken Martyn's response into consideration with my own scripted solution for doing this (gets all requests linked to the "parent", resolves any that are currently open, and sets any that are on-hold to open first before resolving them a few seconds later). This does the job but ideally we need to have the option be able to resolve all linked requests (including on-hold) in the Service Manager app without the need for someone like me to run an external script.

Can someone please confirm if this can be added, and if not, let me know the reason why so I can report back to my colleage?

[Steve Giller]

7 minutes ago, CraigP said:

ideally we need to have the option be able to resolve all linked requests

You should be able to achieve this with an Auto Task using the Resolve Linked Requests node.

 

[CraigP]

Thanks Steve. I've done a bit of testing and an Autotask with that automation seems to do the trick! Is there a reason that the in-app option to resolve linked requests doesn't list on-hold requests while the Resolve Linked Requests automation will go ahead and resolve them? Just want to make sure circumventing the in-app way of doing this isn't going to cause an issue elsewhere.

Another thing I am a little concerned about is that while testing how it interacted with linked requests of various statuses, I noticed that a cancelled linked request still gets marked as resolved when using the Autotask. Is this intentional, and is there any way to avoid this? I'm not sure I understand in what situation you would want to mark a previously cancelled request as resolved.

[Steve Giller]

Actions (i.e. the functional buttons on a Request View) are controlled by various settings and can be locked/unlocked/hidden by a combination of the Service Configuration, System Settings, and Workflow Nodes to reduce the risk of human error - e.g. you can't click a button that is not there.
Workflow nodes are assumed to be placed for a reason and fully tested before deployment, so do not take other factors (for example locked Actions or an existing Request status) into account.

To prevent Cancelled Requests being set to Resolved by the Auto Task they would need to be unlinked when they are cancelled.