David Hall

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.

Hi Michael, The response/fix times are based on a set duration from the point of starting the timers, determined via service level rules ( https://wiki.hornbill.com/index.php/Service_Level_Agreement_Rules_Builder ) , therefore it's not currently possible to set a specific resolve time based on question answer content. As an alternative, the service level rules support the use of "Priority" as a test criteria, so perhaps you could create some priorities to cover the time period required e.g. 1 Day turnaround / 3 Day turnaround / 1 Week turnaround etc, use a suspend for priority node in your BPM workflow and then on manual selection of the appropriate priority (based on the time entered in the question response) you can start the timers via the BPM which will then use the rules to select a service level and timers which have been configured to run for 1 Day / 3 Days etc? Regards, Dave.

Hi @SJEaton, The reminder emails are only be sent if the target is still active, as long as you have marked the response or fix timers in your business process (example of response completion shown in screenshot in the node "Stop Response Timer") then the underlying timer will be stopped and no further reminder actions should be fired. Kind Regards, Dave.

Hi @chriscorcoran We came across this issue yesterday which occurs the first time that you open the customer search form from inbound emails, any subsequent attempts during your session should work correctly until you log out or do a full refresh on the browser. We have a fix in place and it will be available in the next update (build > 1066) which is in testing as I type. Regards, Dave.

Sorry @Martyn Houghton , it should be builds greater 1067+ provided we have no need for any small fix updates in the near future. Regards, Dave.

Hi @Martyn Houghton Sorry its taken longer than anticipated, but the next full update (2.52) which should be out in the next few weeks, I have made some changes to the Update Status BPM flowcode so that if when performing an update, if you choose not supply a sub-status in the node, it will clear the sub-status which should resolve the issue you were having with not being able to reset on resolve. Additionally I have also updated the flowcode so that sub-status will be correctly updated when moving to New/Resolved statuses etc, so you will now be able to set a specific sub-status when moving to a resolved status etc. Hopefully these updates will provide a solution to the couple of scenarios that you mentioned. Regards, Dave.

Hi @carlt Thanks for the post, we've investigated the issue and it is a display issue on the BPM node settings following the addition of new parameters to the email nodes. As you have found, the underlying settings are all still intact and operating as before so there is no need to worry or change anything. A change has been made to the admin tool which will resolve this issue in the UI and make the selected parameters available again so look out for this in the next update of the admin tool. Kind Regards, Dave.