David Hall

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.

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

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.

Thanks @Martyn Houghton I'll see about getting that corrected. Regards, Dave.

@Ann-MarieJones @Logan Graham These errors are likely to be only on these specific requests which were caused before the fix was applied. Someone from our support team should be in contact shortly to see about correcting these specific requests. Kind Regards, Dave.

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}

Hi @Ann-MarieJones @Logan Graham The fix for the issue is already available in the latest Service Manager so that should prevent the issue on any new requests, if you continue to have problems with any existing specific requests then please let us know. Kind Regards, Dave

@AndyColeman Apologies for the error you are seeing, a fix has been created and we'll be pushing out a new update of service manager very shortly to correct this (service manager build > 1453). Kind Regards, Dave.

Thanks for the post @Jeremy we'll raise a problem to handle this. Kind Regards, Dave.

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.

Hi @Lauren Thanks for the update, I believe our support team are assisting you with correcting these existing requests now. @samwoo If you have specific requests to correct then @Victor has kindly said he'll assist further. Regards, Dave.

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

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

Hello Everyone The latest build of Hornbill Service Manager (1451) has been released to live. Change Log for this release are as follows: Fix Restrictions have been applied to the Actions Tabs when viewing a Request in the Employee Portal

Hi @Martyn Houghton Apologies, we have had a recent change to the forum and the automated posts have not appeared. I'll get them added manually. Regards, Dave.

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.

@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 @samwoo @Logan Graham I'll be reviewing this with the team today in order to try to pin point the issue. Regards, Dave

Thanks for getting that for me @Lauren I'll continue to investigate and let you know as soon as I have an update. Kind Regards, Dave

@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.

Thanks @samwoo I'll take a look, I can see the relevant error in the logs, just working on being able to replicate on demand. Regards, Dave.

Thanks @Lauren I'll see if I can find the errors in the logs and review. Regards, Dave.

Hi @Lauren We'll need to investigate this a bit further, do you know what date/time this error occurred and/or what the request reference may have been so that I can have a look in the logs? Kind Regards, Dave.

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.

Hi @Ann-MarieJones The response in this previous post may assist with clarification, if not then please post back. Kind Regards, Dave