Placing multiple incidents on-hold

[dwalby]

Hi all,

We've yet to migrate to Service Manager from Supportworks, but something just occurred to me whilst using Supportworks.

In cases where there are multiple open incidents relating to a problem, we often select all related incidents, update and place them all on-hold (If the problem is pending a change, or 3rd party support, etc.). How can this be achieved in Service Manager?

Thanks in advance

[Victor]

@dwalby although the functionality exists to action on multiple requests at once, the actions available on multiple requests do not currently include on-hold/off-hold actions... 

On top of my head, thinking about how this could be achieved, maybe (big maybe), is to have the BP on linked requests in a suspend state: Wait for Update. Then on the main requests have the BP do an update on linked requests. When the update happens on linked requests the BP on these requests therefore after suspend you can have a node to put the requests on hold. This idea does not cater for many other possible circumstances, hence the "big maybe" but just a thought that it might be achieved...somehow...

Regarding the on-hold/off-hold functionality or action on multiple requests, it would be something that @James Ainsworthor @Steven Boardman can advise on... what, if, how...when...

[James Ainsworth]

There are some definite benefits to @Victor's suggestion.  Where possible, automation can make things easier and remove human error.  

There are some changes in our backlog to improve this further.  One of these is to include the multi-selection option on the request list to but requests on hold.  This may also take sub-statuses into account which in themselves can put a request on hold.  Sub-statuses, in my view, are a good way to go in place of just having an on-hold/off-hold.  

Another option might be for us to include a place on hold or change sub-status on the Link Request action on the requests.  This way as you are making the links between requests, you can place them on hold at the same time.

James

[dwalby]

Thanks @Victor and @James Ainsworth 

With regards to your suggestion of setting the suspend state: wait for update, if this was used within the default incident management BP for example wouldn't this adversely affect incidents which are not linked? I may be misunderstanding, unless this is what you mean by 'This idea does not cater for many other possible circumstances'

[HGrigsby]

Hi 

I have just been asked if it is possible to select a list of tickets and then put them on-hold, as in the original post.

Is it or is it in the list of enhancements, it has just been pointed out to me that Supportworks could do it!

thanks

Helen 

[Victor]

1 hour ago, HGrigsby said:

it has just been pointed out to me that Supportworks could do it

There are other products out there who can do things that Hornbill Service Manager cannot do (yet). I have seen this rationale brought up on several occasions, that Hornbill Service Manager should be able to do X because Supportworks can do it. So, to clarify this: Hornbill Service Manager is an independent product that has no relation to Supportworks. Hornbill Service Manager app is not a continuation or an "upgrade" for Supportworks. It is incorrect to see it as such and it can lead to having incorrect expectations when it comes to it. It is like having a motorcycle then getting an automobile. Different things ... while they are transportation vehicles at base, they are quite different.

So, while it is true that Hornbill Service Manager has inspired from Supportworks in certain parts of its functionality, for all intent and purposes it is a different, independent, non-related product from SW.