Jump to content

Rashid.Ahmed

Hornbill Users
  • Content Count

    18
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Rashid.Ahmed

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi @David Hall Has there been any further developments regarding this issue? Is this potentially a bug? Should we roll back the resolution timer change? Do let me know Regards Rashid
  2. @Victor My apologies Victor, I'll be more mindful of what i post on the forum in the future Your linked post is really helpful to outline what shouldn't be posted on the forum - i've passed the info onto my colleagues too :)
  3. Hi @David Hall Apologies for the various chasers Just to let you know, Some more examples from April of Service Manager incorrectly recording a call as breaching the resolve timer when it clearly hasn’t.
  4. Hi @David Hall Thank you for coming back to me Your update above got us looking at all the calls that are breached like this again 1. We can definitely see calls raised via the self service portal, during working days/hours 2. We could see that Hornbill was still registering that the resolution was met in some way, as when you hover over the breach you can see when the call was actually closed by the system and when all the SLAs should have been taken off pause and stopped ticking complely 3. With just this ticket as an example (we have many since the resolution t
  5. Hi @David Hall We are controlling the pause/resume resolution timers function via the Service Manager Settings: Continuing to use the ticket SR00034450 i've been using for screenshots in this post In the BPM for this call, the 'classification stage' is the only place we have Timer Type nodes set; we don't have timer nodes set in the 'Fulfilment & Closure' stage The timer nodes we have during this stage seem to only be nodes to start the timer
  6. Hi @David Hall Thank you David, really appreciate it! Kindest Regards Rashid
  7. Hi @David Hall Just wondering if this has been found to be a bug or if a fix can be proposed? Regards Rashid
  8. Hi @David Hall Further to my update above The escalate row has the following info attached to it: { "detail": "Resolution Timer Escalated\r\n* The target resolution time has been changed from '''[2021-04-07T15:55:00.000Z]''' to '''[2021-03-29T15:55:00.000Z]'''", "flowcode": "smSLMEscalateResolutionTimer", "prevSysTimerElapsedWorkingTime": "PT0S", "prevSysTimerElapsedTime": "PT6S", "prevSysTimerslcName": "ServiceDeskDefaultCalendar", "prevSysTimerstartTime": "2021-03-22 17:52:40Z", "prevSysTimerstate": "1", "newSysTimerElapsedWorkingTime": "PT0S", "newSysTim
  9. Hi @David Hall Sorry about the belated reply So i've given your instructions a go and using the above ticket as an example i can see that the timer was paused once i resolved the issue, it was then marked as fixed when the ticket closed automatically on the 30th The system then resumed the timer almost immediately, is that correct? I can see that this was the case for the other tickets mentioned in the spreadsheet too- Pause once resolved, then Mark Fixed and resume almost immediatly The ticket is pretty simple in terms of the tasks and the timeline - see below
  10. Hi, I've scanned the forum to see if anyone had already posted this issue, but could've missed it, so please do point me to it if this has already been raised. One of our managers ran a report for the month of March and came upon a discrepancy whereby even though the request resolve by and the date resolved were met, the within resolve time criteria was still appearing as breached (see attached spreadsheet) We applied the Pause Resolution Timer enhancement on the 2nd of March so these calls should adhere to this setting - we confirmed that the enhancement works after the latest
  11. Hi James, We gave this a go last night and unfortunately it still keep the resolution timer ticking even after the call is closed Below is an image showing the settings we enabled (basically matching the image you provided earlier) , what the status of the resolution timer looked like at each stage of the call and finally the report (after the call was closed) confirming the fact that Hornbill still doesn't the resolution has been met. Any advice on how we can get past this issue would be really appreciated Regards Rashid
  12. Hi James, Thank you for your quick reply I think one of the settings that I didn't enable was app.request.stopresolutiontimeronclose setting I will try this tonight and will update yourself via this post on the result. Do let me know if you get any info back from the Dev team, though this additional change to the setting may fix this issue i'm having (fingers crossed) Regards Rashid
  13. https://wiki.hornbill.com/index.php?title=Service_Manager_Business_Process_Workflow#Request_Timers Hi, This forum was particularly helpful with another config change query I had, I was hoping to everyone's brains again? Request Timers; we've recently looked to apply this new enhancement via Application Settings, we have looked to pause the timer on resolve, restart the timer on re-open or end timer on close. We've however found that calls that have been resolved, though they appear as paused seem to also show as 'Timer ongoing' and don't seem to end on close. Our BPM's cond
  14. @Steven Boardman , This is really helpful, i'll look through the post you've forwarded onto me Cheers Rashid
×
×
  • Create New...