David Hall

Hi @Adrian Simpkins Sounds like it should be moving as you would expect, but without seeing the configuration etc it's sometimes hard to confirm whether the timer has not reached a firing time due to a mis-configuration of the escalation time or if there has been an error when it has fired. Perhaps as a test you could try adding a notification/email notification to yourself for each one to see whether you get an email even if the priority doesn't change, that would help to confirm if the event fired or not. If it does fire the event and send the email then there could be an issue specifically with the escalation of priority etc which could be investigated via the log files. Kind Regards, Dave

Hi @Adrian Simpkins I think you pretty much had the correct answer for all three points: 1. The new configuration would apply to new requests as you create them it won't be retrospectively applied 2. If you have it configured to send to owner but no owner is set then it will simply not send an email.. as you mentioned you can configure multiple notifications to contact relevant members as needed 3. The manager is indeed determined from the manager on the user profile, if one is not set then again it simply won't send the email. Hope that helps. Kind Regards, Dave

@Chibamba Great, yes after you have the role and have logged back in, if you view the request there should be a resolve/close tab now shown in the set of action tabs at the top of the request, select that tab and there should be a button option to reopen. Kind Regards, Dave

Hi @Chibamba Welcome and thanks for the post. If you want to manually reopen a closed request you will need to make sure you have the "Full Access" role for the type of request you are trying to open... e.g. to reopen an Incident you will need the role "Incident Management Full Access" or Problem would be "Problem Management Full Access" role. Details of all of the available roles can be found here https://wiki.hornbill.com/index.php/Service_Manager_Roles Hope that helps, Kind Regards, Dave

Hi @Sandip Bhogal Details of administering categories can be found here https://wiki.hornbill.com/index.php/Request_and_Closure_Categories Kind Regards, Dave

I've been informed that the update has now been applied, so the issue should now be resolved. Kind Regards, Dave.

@Jack_Podmore @sprasad @Jeremy @AndyHill @Alberto M Happy to report that we have a fix for this issue and this will be automatically rolled out to you today, so the issue should be resolved shortly. Kind Regards, Dave.

@Jack_Podmore @sprasad @Jeremy Just a quick update, we've identified the underlying issue and a fix is being worked on as we speak, will update you as soon as we have something to make available to you. As originally suggested and now confirmed, the issue will only occur when opening requests that you own, all others will remain unaffected. Kind Regards, Dave

@Jack_Podmore Apologies and thanks for the post. Will investigate the issue now. Kind Regards, Dave.

Hi @Jeremy The top screenshot is the view shown when the service details are not being returned (hence no icons/link/sub-statuses etc). The reason for this will normally be one of... Service has been deleted User logged in does not have the relevant access/visibility to that service Given that you're loading it correctly for existing users I'd guess its the service access for the new user. I'd check first that the new user is within one of the supporting teams on the service, or are appropriately subscribed to the service etc. Kind Regards, Dave

Hi @Daniel When the customer replies to the email from the helpdesk, the email is being processed by your Email Routing Rules and if it matches a request reference etc it will be posted as an entry in the timeline by the system hence (System autoresponder) which is a system account/internal analyst. To communicate further with your customer via email you would continue to reply using the mailbox view or the email tab on the request or simply posting the update with "Customer" visibility will make the comment available for your customer to see on the relevant external portal, the reply mention is not relevant in this case. Replies are for use when collaborating internally e.g. with other members of your team. Hope that helps, Kind Regards, Dave.

Hi @Andrew Tasker Please follow the details at the top of this post to perform an application refresh within the admin tool to correct the above issue. Kind Regards, Dave

@Ann-MarieHolloway The fix for the specific error mentioned by Daniel in the post is for those who have already just updated to the latest update of Service Manager and have not performed an application reload manually, the subscription issue is an entirely separate issue that is being investigated right now. Kind Regards, Dave

@Daniel For that specific error, could you try refreshing the app as described here at the top of this release note post and that should correct that issue. Kind Regards, Dave.

@AKetteringham Great to hear, sorry about that, a manual refresh is not normally required for updates we just have a specific scenario where its required at this time. Kind Regards, Dave.

Hi @AKetteringham I can see you have updated to the latest service manager build.. before investigating further can I just confirm if you have followed the step to manually reload the app as described in this post? Kind regards, Dave.

Hi @Jamie Talbot Thanks for the post. The original intention for autoresponder email updates was to provide an option for "Customers" to respond/provide updates to their requests (Incidents/Service Requests) and therefore currently the attachment/email functionality and related settings are only applicable to Incidents and Service Requests, only a basic update will be applied to other request types. If you have specific needs around this please feel free to post back and they could be considered for future enhancements. Kind Regards, Dave.

Hi @Adnan Zamurred Thanks for the post. I'm guessing you are talking about the request list export of requests? (If not then please let me know) If it is the request list export then the exported dates should use your date/time format settings from your profile settings during export, so it may be a case of altering those settings to a format that you want to use for your export. Kind Regards, Dave.

Hi @Steven Cotterell It should apply retrospectively as this is just a front end correction to the indicator, nothing changed in terms of the underlying data.

Hi @Steven Cotterell Thanks for the post, this fixes an issue for the following scenario... * You have a response due in 1 hour * You place the request on hold indefinitely rather than a specific date * After an hour has elapsed the indicator on the request list would show as red (missed) rather than on-hold/ongoing. Hope that helps, if there is anything else you need let me know. Regards, Dave.

Hi @Ann-MarieHolloway Apologies and thanks for posting, we have already identified the issue and have a fix for this which is currently being tested and we should have that made available Wednesday morning. Kind Regards, Dave

Hi @RobPeck Great news, no problem at all. Regards, Dave.

@RobPeck Thanks for the screenshot, will discuss with the team to see if we can understand why this would only be occurring for a single user. Regards, Dave

Hi @RobPeck Strange one. It looks like you are using Chrome, if so if you open the console (ctrl + shift + I) and reload the new request page, do you see any errors in the console? Regards, Dave

Hi @RobPeck The status on your instance looks OK and I'm not seeing this issue locally. Have you tried clearing browser caches etc as a first step? Just for further information, is this affecting all users or just yourself? and are other Hornbill views broken in the same way or is it just raising requests? Kind Regards, Dave.