Jump to content

David Hall

Hornbill Developer
  • Posts

    549
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by David Hall

  1. All, This is an important message on how to ensure that your processes continue to run smoothly after 31/10/2021. The priority-based Service Levels (i.e. the configuration in the Service Levels tab shown below on the service portfolio view) will no longer be functional from this date, all service levels/targets will now need to be handled via the Service Level Agreements tab. If you do not see the service levels tab or the red notice then there is no action to be taken. See more on this and on how to migrate here Hornbill How To: Transition to the new Service Level Agreement functionality - Hornbill
  2. Hi @Berto2002 If you are using the standard selectors for selecting a service in the new request node etc then renaming the service should not be a problem, the logic will all be based on the underlying service id. The only way in which you could see an issue if you have specifically referenced the name of a service in any custom expressions when branching etc. Kind regards, Dave.
  3. @Kelvin @Mike Hillman Just an update that the patch has just been deployed... sometimes it can take a few mins to be noticeable with caching etc but the issue should now be resolved... if you can keep and eye on it this afternoon and let me know how it goes. Kind Regards, Dave
  4. @Mike Hillman We're building the patch now so it should be rolled out this morning, I'll post back here once this has been done. Kind regards, Dave.
  5. Hi @Kelvin I've managed to replicate the issue and we now have a fix which is currently being reviewed/tested, we'll look to get it patched as soon as possible, most likely tomorrow morning. Kind Regards, Dave.
  6. Hi @Berto2002 Glad the issue has corrected itself after a cache clear. Regarding the linking of corporate SLAs, typing into the field should provide you with a filtered list of corporate SLAs that you have configured within the service portfolio so it should filter and display results from the list shown under the Service Portfolio View -> "Service Level Agreements" tab. Once you have an SLA selected the link button will be active. Kind regards, Dave
  7. Thanks @Kelvin Will take a further look now. Kind regards, Dave.
  8. Hi @Kelvin Thanks for that update.. indeed something is not correct there. So just to confirm those 2 incorrect entries that you have shown... were they logged via self service portal or via the Employee portal? Also just wanted to confirm whether the site in these cases is set via manual selection in the progressive capture or via a business process action? Regards, Dave
  9. Hi @Berto2002 I've just been trying to recreate. Can you confirm whether you opened the links to the service or new service view via the Service Portfolio list or did you access the links directly? Also would just confirm that you have cleared cache etc in case there is an issue with the page loading following this morning's update. Kind Regards, Dave.
  10. Hi @Kelvin I'm not aware of any site specific changes in this latest update. I've had a look and tested locally and I don't appear to be able to replicate this issue for existing or newly logged tickets which all display the site name for me. As a first step I'd just like to confirm you have done the usual basics with a log out/clear cache/log back in and then see if the issue persists. After that perhaps confirm if any colleagues are seeing the same issue? Let me know if the issue persists. Kind Regards, Dave.
  11. Hi @Brhow I've checked with our teams and there may have been a issue with your instance that could have led to this issue. The issue should already have been corrected so if you could try this now and let us know if you still have issues. Kind Regards, Dave
  12. Hi @JoanneG We've implemented a fix for this issue, it may be too late for the fix to make it into the next update, but if so it will be available in the following update. Kind regards, Dave
  13. Hi @JoanneG After some further investigation we've managed to replicate the issue you are having, we'll get a problem raised to investigate further and get the issue corrected. Kind regards, Dave.
  14. Hi @JoanneG If you start typing the name of the asset in the field then it should give you a list of assets to select from as per the screenshot... do you get any list shown at all? Kind Regards, Dave.
  15. Hi @Paul Alexander Thanks for the post. I've had a look and will get a fix in place for the next update so that it will break correctly on full words as per the employee portal view. Kind Regards, Dave.
  16. Hi @Jeremy Thanks for the feedback, we raised this internally just the other day and we'll get it corrected in a future build. Kind Regards, Dave.
  17. Thanks for the feedback @Paul Alexander I've passed it on to get this looked at. Kind Regards, Dave.
  18. Hi @simonadams From the Request List view if you click on the cog at the top right to configure the available columns, there is a column named "SL" or "SLT". If you select that column to be available in your view then you will see the indicator dots made available. These will alter in colour based on the current state of the service level timers you have running against the requests. Hope that helps, Kind regards, Dave.
  19. Hi @Rashid.Ahmed I've still not been able to fully replicate locally but I have a suspicion it could be down to the fact the request was raised out of working hours and then escalated immediately before any time elapsed. I'm just trying to recreate that scenario to see if I can confirm whether that is the reason for the resolution time being incorrectly reset. Will let you know when I can confirm or not. Kind Regards, Dave.
  20. Hi @ALIPO You should be able to click from the Hornbill Main menu choose "Customers" -> "Organisations" and add from there Kind Regards, Dave.
  21. Hi @Rashid.Ahmed Just to check.. are you using the BPM nodes to control the pause/resume or are you using the app settings e.g. app.request.pauseResolutionTimerOnResolve to do it automatically? Kind Regards, Dave.
  22. Hi @Rashid.Ahmed Sorry I've been on leave hence the lack of recent reply. Based on the debug info you have posted let me review and see if I can determine what is happening in this scenario. Kind Regards, Dave.
  23. Hi @Rashid.Ahmed It does look incorrect but its pretty hard to confirm from the screenshot, sometimes changing an SLA after a target has already been missed etc can result in this view for example. If there has not been an SLA change to cause this scenario, if you have the "Incident Management Full Access" role you should be able to click on the blue button under "Service Level" to open the SLA update popup. To the bottom right of the popup there is a diagnostics button which will show a list of the primary SLA actions e.g. pause/resume etc. It might be worth checking that to see if that shows when the pause and resume took place and when the resolution/fix target was marked to see if that highlights any reason for the above. Kind Regards, Dave
  24. @Michael SharpI've just reviewed this and can see the reason. To clarify, the h_withinresponse value (and h_withinfix value) are only set when the target is confirmed as being within or outside of the target time. This has always been the case and continues to be so. Regarding your question on this request, if I read the screenshot correctly, the target response time was 12:05, the target was missed and then at 12:06 the SLA was changed which altered the time to an hour ahead. In this scenario because the target had been missed at the point at which the SLA was changed, we set the h_withinresponse to 0 hence why it will not be appearing in the results. If the SLA change was made before the target time then the value would have remained as null. Hope that clears it up, Kind Regards, Dave
×
×
  • Create New...