Jump to content

David Hall

Hornbill Developer
  • Posts

    557
  • Joined

  • Last visited

  • Days Won

    19

Posts posted by David Hall

  1. Hi @Jeremy

    Apologies if you were experiencing slowness in Service Manager.  I've just checked here and it seems there was some heavy loading on the database which was causing some performance issues.  I've been told this is now resolved and the speed should have picked up.  We'll continue to monitor it and if you experience any further problems please post back.

    Kind Regards,

    Dave.

  2. Hi All,

    The latest build of Hornbill Service Manager (1489) has been released to live.

    Change Log for this release are as follows:

    Fix

    • When associating assets to a request using advanced search, dynamic drop down items do not load {PM00155820}
    • Max open time is incorrectly calculated due to an issue with timezone
  3. Hi @Lauren

    Great stuff, glad you have the info you need. 

    There are no current plans to include the actual fix/response duration within the request details. Currently we are showing the target time (for running targets) or the datetime completed (on completed targets) to assist the analyst. I don't think to this point we've seen a benefit to the analyst of having the completed target durations shown on the request details, we've seen that information as more of a management/reporting interest.  If you have a good use case of how you would use it then please post back and it can be considered for a future change.

    Kind Regards,

    Dave.

  4. Hello Everyone

    The latest build of Hornbill Service Manager (1459) has been released to live.

    Change Log for this release are as follows:

    New

    • New operation called 'Requests > Entity > Integration > Log New Service Request' to provide integration with other Hornbill applications to raise a Service Request

    Fix

    • Alteration of Request timers can fail when one of the timers has already been completed {PM00155202}
    • Taking a Request off hold may error when no service level agreement is in use {PM00155291}
    • Exporting a View excludes values in custom columns 21 - 30 {PM00155226}
  5. Hi @Claire Holtham,

    Also thanks @Lauren for your update.  The fix was available in the 1452 build, apologies it appears to have been missed off from the release notes as I added them manually this time due to some issues with our automated posting, I'll correct that.

    To the best of my knowledge the originally reported issue has been fixed and should not present a problem.

    Kind Regards,

    Dave.

  6. Hi @Dan Munns

    Thanks for the post.   I've just been investigating and it looks like there may have been a rights issue in the build of the Service Manager app that you are running which has been corrected in the build made available today (1452).  Once the latest update is applied this should fix your issue, if it persists then please post back.

    Kind Regards,

    Dave

  7. Hello Everyone

    The latest build of Hornbill Service Manager (1452) has been released to live.

    Change Log for this release are as follows:

    New

    • Progressive Capture designers can now branch workflows and use different forms based on the source of the request being an email in the same way that it is already possible by portal or agent
    • Advanced searching has been added to the link assets action on requests
    • You are now able to remove an entry from the Questions section of a Request if you're assigned the "Service Manager Delete Questions" role

    Fix

    • The email composer shows an empty file attachment size when there are no attachments {PM00154952}
    • Service Manager setting to set default Request Timeline order is not applied {PM00154974}
    • Changing of Service Levels or taking a request off hold could fail when no working time has elapsed on the service level timer to that point
  8. Apologies again for the problems @Lauren,

    As per my previous post, we've made some changes which we believe will correct the issue and failing that will provide us with some additional logging information to work with. 
    The changes and additional logging are in place for the the next full update which excluding any unforeseen issues should be available for you to install on Monday.  Once you have the update in place we can look to see if the issue still persists and if so we will review it with the additional logging as a priority.

    If you have any questions please let me know.

    Regards,

    Dave.

  9. @Lauren @samwoo @Logan Graham

    We've reviewed this issue further but still are unable to confirm the exact set of circumstances that lead to the error. 

    As a result for the next update due out in the next week (build 1448 or greater), we've added some handling for the issue which we expect to resolve the error and accompanied this with additional logging to help with any further diagnosis should the need arise.

    If you continue to see issues after this next update please let us know back here so we can follow up.

    Kind Regards,

    Dave.

    • Thanks 1
  10. @Lauren @samwoo

    With regards to the above references you have mentioned, I was just looking to understand the request lifecycle and ask if:

    1. Was the Service Level updated (either manually or by auto SLM rule updates) prior to the hold/take off-hold action?

    2. Had the request been placed on hold until a specific time or just indefinitely using sub-statuses

    3. Is it possible at all that the related BPM process calls the Mark Response/Fix node around this point e.g. based on a status change? 

    Whilst I can see exactly where it is failing I'm currently unable to replicate locally and haven't as yet been able to understand under what scenario this situation arises so any information you can give would be appreciated while I continue to investigate.

    Kind Regards,

    Dave.

     

  11. Hi @Keith

    As always this is somewhat complicated to explain so if the following is not clear then don't hesitate to ask further questions...

    Until now, when changing a service level on a request, the new target times have been recalculated as:

    * Original Target Start Time + new SL duration (applied according to the associated working time calendar)

    However, we have never taken into account any working time spent on hold, so you could end up in the following scenario:

    SL1 Resolution Duration = 1 Hour
    SL2 Resolution Duration = 4 Hours

    SL1 Request Raised and Target Started: 9am - Target is 10am
    SL1 Request Placed on Hold: 9:10am Until 2pm
    SL1 Request Off-hold @ 2pm: New target is 2:50pm

    At this point (2:50pm) the SL is deemed incorrect and should be downgraded to SL2

    SL2 is Applied to Request: New target is 1pm (9am + 4 Hours Duration) [Target is already missed despite being lengthened]

    The effect of this new setting being enabled is to handle situations as above, so with the setting on we will now see the calculation as:

    SL2 is Applied to Request: New target is 5:50pm (9am + 4 Hours 50 mins (on hold) + 4 Hours Duration)

    If you want to revert back to the previous method of operation then changing the setting will revert you back to the original calculation method.

    Kind Regards,

    Dave.

×
×
  • Create New...