David Hall

Hi @Drew Davies I think this post probably provides the best response to your question. I will ask our Product Managers to review this again in response to your post. Kind Regards, Dave.

Morning @J_Tamburrini The actual process of applying the service level is the same via email or manually via the client, however its the context that caused the problem in this case as its a system account that does the work when logging via email, rather than the analyst account when logging manually. The fix is now in beta testing and we are working on releasing an update as soon as possible. Kind Regards, Dave.

Hi @J_Tamburrini Thanks for the post, following further review we have identified an issue with the setting of service levels via autoresponder and a fix will be in the next update of service manager. Kind Regards Dave

Hi @Rohit Govind Apologies for the inconvenience, I've reviewed the logs and identified an issue with a recent fix to service levels which has had an unexpected knock on affect in this case. I will have this fixed in the next build which will be pushed out as soon as possible, but as a workaround, in the meantime, you may wish to change the following service manager setting in the admin tool to "off" which will force the system to use the priority based timers. guest.app.view.ITSM.serviceDesk.enableSLM Kind Regards, Dave

Thanks @Rohit Govind Yes that would indicate you are on the original priority based timers, I'm just reviewing your log files and I'll update you shortly. Regards, Dave.

@Rohit Govind If you open the Service Manager -> Service link from the home menu, you should see the tab for configuring your service levels... is the tab you use for configuration named "Service Levels" or "Service Level Agreements" ? Regards, Dave.

Hi @Rohit Govind Can you confirm if it is the original priority based service levels that you are using? Kind Regards, Dave.

Hi Andy, We'll change the white text colour to a dark grey for closed changes in the next update, so when you have that update it should be much more readable. The next update is currently in QA testing so all being well should be available to you within the next 1-2 weeks. Kind Regards, Dave.

Hi @Gary@ADL I've just reviewed the logs for that specific ticket you referenced and according to the logs the email was not applied because the incident was in closed status and you do not have the setting enabled to allow updates to closed incidents the sender's email is matching more than one record in the user table, hence the routing rule is unable to establish who is actually the sender. Check the admin account, it has the same email address as your user... If you wish to enable the setting for closed incidents you will need to update the following setting via the Admin tool -> Hornbill Service Manager -> Settings: app.email.routing.rules.allowClosedCallUpdates.IN It seems the issue will only occur if you are sending the email (not sure if there are more than one user with same email address though) so no other email should be affected. I would also suggest a different email address for the admin account if you like... this is the advantages of having your email address on admin account overweight the downside of having to apply emails from your email address manually... Hope that helps, Kind Regards, Dave.

Hi @J_Tamburrini We had a look at the speeds of your instance but there was nothing unusual that stood out. Kind Regards, Dave.

Hi @MikaP As you say when the social links are set to 0 I do not see any links shown in the customer portal, could you perhaps provide a screengrab of where the icons are still showing? This was what I can see on my system Regards, Dave.

Hi @dwalby I've just tried it myself and it worked for me as per the screenshot. Obvious thing to check might be just to make sure you are editing the settings for the correct portal as there are separate settings in the admin tool for the customer and the service portal. Regards, Dave.

@HHH Yes that would be the correct way to do it if you are wanting to track your response and fix times from the point at which the request is raised. Regards, Dave.

@dwalby Great stuff

@dwalby The sub-status will only be updated from within the request if it is manually changed by the user, to make it more configurable (via BPM) there is no automatic updating or resetting of the sub-status when resolving/closing etc... this should be built into the BPM process as you have now attempted to do. Regarding the error, I have checked myself and if you include a node to update the sub-status with the settings shown in the attached screenshot then it shouldn't error and it should reset the sub-status. Let me know how you get on. Regards, Dave.

@dwalby If you have added in the update status node (as in your original screenshot) but set the sub-status setting to "Auto" then it should still reset the sub-status even if the primary status hasn't changed, e.g. if you have already set to "resolved" manually and then this node is called setting status to "Resolved". The only time it would not make any changes would be if the status and sub-status values are both unchanged. Regards, Dave.

Hi @dwalby As @Martyn Houghton suggested if you just leave the setting for Sub-Status in the BPM node as "Auto" then the it should be reset when the node is run. When set to manual with no value it set it returns an error as it is expecting a value to have been selected. Kind Regards, Dave.

Hi @lee mcdermott You can find an overview of the notifications here https://wiki.hornbill.com/index.php/Notifications Kind Regards, Dave.

Hi @Chris Temple As you have identified, currently the content of the email notifications to analysts is currently hardcoded in such scenarios. We have a feature request already raised which would look to enable these to be configurable via email templates so I will add you to the list of interested customers. Kind Regards, Dave.

@Martyn Houghton Yes, just had a look at that change and that makes perfect sense. I've mentioned James with regards to this post so we can make sure we have captured all of the relevant details within those two changes. Cheers, Dave.

Hi @Martyn Houghton Currently the increase Priority by 1 will as you suggest just update the priority value on the request record based on the order of the priorities in the priority list. We have an existing change in our backlog (CH00142342) which would look to automatically reassess/reapply the SLM rules that are configured whenever you change the priority/customer/site etc on a request which I guess is what you are looking for? I will add your interest to that change. Kind Regards, Dave.

Hi @derekgreen We don't currently have any rights or role restrictions around the assignment of a request, it is just a standard action that is permitted provided you have rights to view a request and update a request. Perhaps you could expand on the scenarios in which you would want to restrict access and it may be considered for a future change. Kind Regards, Dave.

Hi @Martyn Houghton Apologies I missed this post, the method of using sub-status is really the only option right now as when we stop timers they are removed, so it cannot be reinstated from its previous position it would always require a new timer to be started. Regards, Dave.

Hi @yelyah.nodrog The manager lookup for breach notifications is indeed looking at the data that you have in your screenshot, however it will be looking for the manager of the current owner of the request, rather than of the person who raised the request. Currently it is only possible to send the notification to the request owner, or the manager of the request owner, so if you do not wish to send the notification in this case as you suggest, then I would suggest within your targets just turning off the "Send Reminder" checkbox as per this screenshot and this will prevent notification emails from being generated. Hope that helps, Kind Regards, Dave.

Hi @JBasey, The "Last Updated" field is just a "duration since" representation of the "Last Updated Date" field which is just the point in time that the last update occurred, so there is no concept of working time here at present. Perhaps you could expand on how you wanted to use it to see if there are any alternatives or to put forward a case for a future addition. Regards, Dave.