Recently, I was working with a client who wanted to update an HP Service Manager interaction, (ESS ticket), when the ticket was escalated to an incident, and an assignment had been made, with the name of the assignment group, and the assignee (if selected).
I initially thought this would be simple, by adding an activity action in the incident ticket when the assignment and assignee.name are initially set, and setting the cust.visible flag to true. This would allow me to let HPSM do the work, and the update would automatically be sent back to the journal entries/activity journal on the interaction. While this works great for all incident updates, it doesn't appear to fire on the actual open of the incident.
One of the hurdles we came across, was when the activity record was created. Unfortunately, the timing was such that the actual relationship between the interaction and the incident had not yet been created. Because of this, some of the automatic logic doesn’t fire, as it doesn’t know about the “related record”.
To get around this, we decided to use the incident.id field in the probsummary table to reference the related incident. Now before everyone gets upset, for our purposes, this works. We are looking for the INITIAL assignment of SRC generated tickets, and we don’t care (at this point) about multiple interactions assigned to a single incident.
So in summary, this is what a Techport Thirteen peer and I implemented:
- New activity action on open, when assignment and assignee.name are not null, on probsummary open
- Cust.visible flag set to tru on open in probsummary FC
- Trigger on the activity table, with logic to create an activity record for (soon to be) related SD record
Our solution worked well and met all use cases. Interactions are now being updated with assignment data.
Have another option we should have considered? Let me know your thoughts by leaving a comment below.