Connections

[Guest Sonali]

Hi 

I am tying to understand how connections are used within the incident process. So for example, if I have an incident already raised and then another user calls to report the same issue - then this user would be added to the original incident as an impacted user - correct?

Therefore when I add this user as an impact user (which could be at any stage within the BPM), how do I inform them of the incident number and their call/issue has been associated with this incident?

Also how do I inform the impacted users that the issue has been resolved i.e. closed as part of the BPM. I have a node to email the customer informing them that the incident has been resolved but how do I include the impacted connections?

Sonali

[Victor]

@Sonali there is a node to email connections as well... 

[Steven Boardman]

Hi @Sonali

Connections can be used for a variety of purposes in different request processes, but there maybe other options for the scenario you mentioned in Incident Management.

I would think that you could look to record each Incident as a separate record, so if one customer has reported an issue and another customer calls in with what sounds like the same issue, i would still record these as separate Incidents.  

If we start to see a pattern developing then you could either group these Incidents under a Major Incident, using the Link Request Feature - and then from the Major Incident you could use the Business Process options to Update the Linked requests at key points, and or use the Resolve / Close Linked Requests feature from the Major Incident to the child Incidents once the Major Incident is resolved.  One of the options with the Resolve / Close Linked request feature is the ability to email the customer of the linked requests automatically and also notify the owners of the child Requests. 

The above could also be true for the use of Problems and Known Errors - here again you can link multiple Incidents to a Parent Problem or Known Error. 

Where Connections play a nice feature in Problem Management, is the ability to publish known issues to your customers on the Portal, and provide them with a quick and easy way of associating themselves to said known issue, without the need to raise a new Incident / Request, and for the Problem Management team not to have to go looking for and linking Incidents to the Problem / Known Error. 

So from a Problem / Known Error record , you can use the Publish action, and this will make the known issue visible on the Service / Customer Portal, where customers can use the Me Too button to add themselves as affected users (connections) to the known issue.  

As Victor has suggested above, you can then use the Email Connections business process option in your supporting business process, to keep the affected connections informed of progress or resolution of the known issue via email automatically. 

To come back to where Connections could be used in Incident Management, you could add interested parties to an Incident and then again use the Email Connections business process option to keep them informed of progress, or you could also include them on manual communication you are sending from the Incident, by adding them in bulk to the cc or bcc fields based on their connection to the Incident (Interested, Impacted - bearing in mind the list of connection types is definable in a simple list in the admin tool).

I hope that helps

Steve

[samwoo]

1 hour ago, Steven Boardman said:

Hi @Sonali

Connections can be used for a variety of purposes in different request processes, but there maybe other options for the scenario you mentioned in Incident Management.

I would think that you could look to record each Incident as a separate record, so if one customer has reported an issue and another customer calls in with what sounds like the same issue, i would still record these as separate Incidents.  

If we start to see a pattern developing then you could either group these Incidents under a Major Incident, using the Link Request Feature - and then from the Major Incident you could use the Business Process options to Update the Linked requests at key points, and or use the Resolve / Close Linked Requests feature from the Major Incident to the child Incidents once the Major Incident is resolved.  One of the options with the Resolve / Close Linked request feature is the ability to email the customer of the linked requests automatically and also notify the owners of the child Requests. 

The above could also be true for the use of Problems and Known Errors - here again you can link multiple Incidents to a Parent Problem or Known Error. 

Where Connections play a nice feature in Problem Management, is the ability to publish known issues to your customers on the Portal, and provide them with a quick and easy way of associating themselves to said known issue, without the need to raise a new Incident / Request, and for the Problem Management team not to have to go looking for and linking Incidents to the Problem / Known Error. 

So from a Problem / Known Error record , you can use the Publish action, and this will make the known issue visible on the Service / Customer Portal, where customers can use the Me Too button to add themselves as affected users (connections) to the known issue.  

As Victor has suggested above, you can then use the Email Connections business process option in your supporting business process, to keep the affected connections informed of progress or resolution of the known issue via email automatically. 

To come back to where Connections could be used in Incident Management, you could add interested parties to an Incident and then again use the Email Connections business process option to keep them informed of progress, or you could also include them on manual communication you are sending from the Incident, by adding them in bulk to the cc or bcc fields based on their connection to the Incident (Interested, Impacted - bearing in mind the list of connection types is definable in a simple list in the admin tool).

I hope that helps

Steve

@Steven Boardman This is Wiki material! You have a lot of detailed posts in this forum in response to somone on here which is absolutely fantastic and they have all been so detailed, I think they should be on the Wiki somewhere... maybe a question / answers section or to include the examples you provide against the relevant sections in the wiki? This way we can refer to your response on there (maybe with a link back to the post in question).

For example, If i do a search for "Connections" - https://wiki.hornbill.com/index.php?search=connections&go=Go&title=Special%3ASearch there is no results specifically related to "Connections", but there are results where some details of connections would reside in.

Great post Steven, I hope @Sonali has found the information as useful as I did. I don't think we've ever used Connections as part of the Incident or Service Request... would these users be able to see these requests in the Portal if they were a connection?

Thanks,

Samuel

[Steven Boardman]

Thanks @samwoo

I think that is a great idea about getting some of this content / FAQ's etc on the wiki and i'll certainly look at the best way to do this / present this. 

In regards to the connections of an Incident / SR, they do not currently see these requests via the portals, but it is again a nice idea.  I can see several use cases, including the obvious one, of raising a request on behalf of someone else. 

We have a story in our queue which relates to adding connections as part of progressive capture, so this could be a natural evolution of that. 

I'll post back here when we have made progress in this area

Steve

 

[samwoo]

1 hour ago, Steven Boardman said:

Thanks @samwoo

I think that is a great idea about getting some of this content / FAQ's etc on the wiki and i'll certainly look at the best way to do this / present this. 

In regards to the connections of an Incident / SR, they do not currently see these requests via the portals, but it is again a nice idea.  I can see several use cases, including the obvious one, of raising a request on behalf of someone else. 

We have a story in our queue which relates to adding connections as part of progressive capture, so this could be a natural evolution of that. 

I'll post back here when we have made progress in this area

Steve

 

Brilliant, the wiki is going to be a masterpiece (it's good now already).

Thanks for thinking about my idea. Maybe one could specify what type of connections can view assigned calls in the Portal, for example it would make sense to link a New Starter as a connection to the Portal and for the New Starter to view the call, but it doesn't make sense for connections related to Infrastructure Project work to view calls in the Portal.

Really looking forward to adding connections as part of the Progressive Capture.

Many thanks,

Samuel