Escalation Events and highlighted requests on list

[Alberto M]

Hi all.

As per the Hornbill Wiki, a request appears in color in the requests list for "Requests which have been updated by anyone but the owner of the request, and the owner has not yet read the update."

I have the escalation events that are generated having impact in this in a way that, if an escalation event is triggered, it updated the request timeline and acts as if a real person had updated the request, which makes our analysts to not trust the colors in the requests list.

Is this supposed to work like this? Is there any way to avoid the escalation events to update this? My colleagues are expecting that the colors only change when a real person updated the requests.

Cheers,

Alberto

 

[Deen]

@Alberto M I cant see anything in the application settings that would treat escalation updates differently to other non owner updates.  The only potential way around this that I can see would be to disable the following so that the escalation doesn't actually post to the timeline.

Post to Timeline - Tick if you want the notification text to be posted on the timeline of the impacted request

 

[James Ainsworth]

Hi Alberto,

This is the intended behaviour. The colour change does represent any update to the request, whether it be human or automatic. This ensures that the owner is aware that an update has taken place.  Something like an automatic escalation could actually have more importance than a human update.  With BPM automations most of the nodes will have an option to not include a timeline entry.  If there are particular types of BPM automations where you don't feel that the owner needs to see the colour change in the request list, you can select to not have a timeline update.

Hope this helps.

James

[Alberto M]

Hi @James Ainsworth

I agree with you that the escalations are a very important update to a request, but we are using escalation email notifications to the owner (as well as other owner's team members, depending on the SLA breaching severity), so, the owner is aware that the request is about to breach SLA or have breached SLA, but the "updated by anyone" concept of the colored list request get spoiled by this turning it to almost useless, as analysts want to see quickly if there was someone - a person - updating any requests from his/her list. 

As these updates are generated by triggered SLA breaching and not by BPM automations, a global setting to turn this on, or off, could be nice.

Cheers,

Alberto