Problem tickets no longer have HUD capabilites

[mmensah]

Good Morning All,

 

I'm reaching out to see if anyone else has experienced this — and if so, how you've managed it.

Recently, we noticed that the Heads-Up Display (HUD) for Problem tickets in Hornbill Service Manager is no longer visible. This seems to have changed without a corresponding update notice that we could find. Prior to this change, our team relied heavily on the HUD for quick access to key ticket information such as linked incidents, major problem indicators, and escalation statuses.

The removal of the HUD has disrupted an established process that was critical for managing ongoing problems efficiently and while we understand platforms evolve all the time, the sudden change has impacted both service delivery speed and incident management quality.

Has anyone else run into this issue?

Kind regards,

Martin Mensah

[Conor]

Morning @mmensah

Just to confirm that this hasn't been removed - it is still working for me:

 

There could be a few reasons for the missing HUD, and the fix could be as simple as a browser refresh. A common reason that there isn't a HUD, is that there isn't a workflow running against the problem call class for the service that the problem is logged against?

[Foley Coker]

Hi @Conor, I'm reporting from the same organization as Martin. 

 

there is a workflow behind the process, but when we copy or log new calls the HUD isnt invoked. Looking at the service portfolio the option for the  portal HUD stages and checkpoints is missing, as opposed to the other ticket type settings, please see below examples. We cant pinpoint when this change happened,  but previously logged tickets still show the HUD and follow the workflow but new tickets do not invoke the workflow at all, human tasks etc.. we couldn't find any notes on this change and was wondering if this is intentional change to the way problem tickets are offered similar to known error / release. 

 

[Steve Giller]

@Foley Coker The most likely reason is a change to either the initial workflow that generates the second request, or to the workflow the second request expects to utilise that prevents it from spawning.

As a first step I'd check the last updated date of the second request's workflow template and see if that correlates to the HUD disappearing.

[Conor]

@Foley Coker the workflow drop down in the top left of that screenshot has the workflow as empty, which could also be the reason. 

From my brief testing if I get rid of the workflow from that top left drop down against the problem call class, and then log a problem, then I get the same as you - no workflow and no HUD. As Steve mentions above if the workflow you were using that was defined in that drop down has now been marked as deactivated somehow, then that drop down would be cleared. I'd try adding the relevant workflow back into that drop down box and I reckon the HUD will then display for the next problem logged. 

[Foley Coker]

Thanks @Conor & @Steve Giller the problem is resolved, we took the steps as described and will be looking more at what is configured in each of out service portfolios, and request types. Although if there is anywhere you can point to in the guides that explain a bit more on why a singular specific workflow selection in the service area would affect various different workflows in the catalogues of the same service area, that would also be helpful for our understanding.