Adding connections when linking tickets to MI

[Guest Paul Alexander]

Hello

We use the concept of Major Incidents, which means that we have quite a few tickets which are linked to a Major Incident ticket to save us having to deal with a lot of 'separate' tickets. ( I seem to be saying 'ticket' a lot...)

Anyway...what I'd like to know is....is there a setting or a way of automatically adding the 'customer' of a linked ticket as a connection on the 'major incident' parent ticket so that, if an email update is made to the MI, it can then cascade to all of the connections? I realise I can add the connections manually, but a setting or a way of handling this through a BPM (bearing in mind a ticket could be linked to the MI at any point in the MI process) would be much easier....

 

thanks

Paul

[nasimg]

This is something I would be interested in - but also have the multiple action button have email as a function (for multiple selected requests).

Nasim

[Hornbill Staff DR]

Hi Paul,

 thanks for your post. 

The addition of connections seems to be ancillary to the primary requirement which is to communicate with a broader group of individuals more efficiently. In this case, the group of individuals is composed of those that are currently the customers of linked requests.

The feature that would be applicable here would be in the form of a bulk email from the request list (which would be along the lines of what Nasim mentioned) , or the ability to apply an update to all linked requests and, if that was an email update, send an email to the customer of the request as part of that action.

Unfortunately, that specific capility doesn't currently exist within Service Manager. I understand there are plans for its introduction but at present I can't supply any further detail on timescales etc.

I can see that you are trying to accomplish this through the use of connections, which is potentially the best solution when it comes to emailing a group of individuals, as we can add connections quickly to an email. However, as you point out the association of a connection is ad-hoc and doesn't occur at any particular point in the life-cycle of an incident. If an action is ad-hoc, the BPM is not be best-placed to facilitate this and so it would be questionable whether a BPM operation you describe would give you the value that you desire.

Self Service Bulletins offer a mechanism to broadcast information to customers. Of course, it depends what information you are trying to convey in these bulk updates. If it's a generic holding response a bulletin could serve this communication need,  if it relates to detailed resolution steps, then this suggestion may be less appropriate.

Could you elaborate more on the type/content and frequency of communication that takes place as part of your Major incident process?

Thanks,
Dan
 

[Steve Giller]

This is a function of a similar type to the one mentioned here: 

In as much as it's a procedure that happens during a Business Process but is not directly connected to it.
It's a tricky area, as it's while you could deal with these ad-hoc but common events it would be difficult to do so and maintain the non-programming ethos of the system.

The only thing I could think of would be to allow additional processes that are triggered by specific events, e.g. a Request Cancellation BP or a Linked to Major Incident BP - but you would rapidly end up with an unmanageable amount of options per Catalog Item.

[Guest Paul Alexander]

Hi @DanielRi

Apologies...I completely forgot to reply to your message!

Basically, we're looking for a way to update affected people with either some information about what's happening with their particular incident, or even just to let them know that SOMETHING is happening, or, if there's a question we need to ask the users .....

I suppose an option to message the Customers of all of the linked requests would be easiest, rather than adding them as connections (obviously I'm saying this from a 'using the tool' perspective - not what would be easiest from a dev point of view!)

I do understand that bulletins in the Portal would be an option, but I'm not sure that our users are quite 'there' in regards to using the Portal as the place to check for updates at the moment, so email would be a good option in our case.

Is that any help?

thanks

 

Paul