David Hall

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.

Hi @Paul Alexander I thought we previously had indicators for mandatory fields, but it turns out it was never the case. I asked the question with the developers working on the admin tool and they have added red visual indicators for mandatory fields for the next update to the admin tool, so you should have indicators shown following the next update (build > 709) which should be within the next few weeks. Regards, Dave.

Hi @Paul Alexander, Hard to be sure without seeing the configuration of the node in your BPM, but the error would suggest to me that one of the required parameters for the BPM node (requestId, onHoldPeriod, reason) has not been set. Might be worth reviewing those as a first check. Regards Dave.

Hi @Stuart Torres-Catmur Apologies, we have had a few issues with the update build numbers and update notes in the last few service manager updates, this will be rectified for the next update. In the meantime, should you wish you can visit https://forums.hornbill.com/forum/135-announcements/ to see the service manager update announcements which will provide you with details of the content of each of the previous updates. Kind Regards Dave.

Hi @Dan Munns @nasimg Apologies for the missing change log. I personally don't have access to add them, but we're aware of the problem and we'll get them added as soon as possible. Regards, Dave.

Hi @Martyn Houghton Just following up on this, I did have a working fix for your immediate issue, however there have been some other questions raised in the past week or so by our product specialists around when we should be resetting sub-statuses and and which statuses should trigger sub-status updates etc. As a result I'll be having a discussion with @James Ainsworth about this area to make sure we are happy with the solution before we put it into the build, I will let you know as soon as we have the solution ready. Regards, Dave

Hi @SJEaton If I understand your requirement correctly it sounds like you would want to have a look at the "Advanced Request Task Completer" role as shown in the screenshot. Hopefully that will give you what you need. Kind Regards, Dave.

Hi @Gary@ADL Its most likely just some additional settings that would need to be altered to get the other flowcode working as you would like, but in any case I have the fix in with the updateRequest flowcode for the 2.51 release so that should be available to you soon. Regards, Dave.

Hi @Keith As far as I can tell the cache issue has now been cleared, so if you could give it a refresh and try it again now and let me know if you still have any issues. Regards, Dave.

Hi @Keith Apologies, it would seem that we have had an issue with the file caching following your update yesterday which has meant that a broken version of the file needed for applying emails has been cached hence the issue you are experiencing. We are working to clear the cache issue and as soon as I can confirm it is fixed I will let you know. Regards, Dave.

Hi @Keith Sorry to hear that, just investigating now and will update you when I know more. Regards, Dave.

Hi @Ralf Peters We've had a review of the update log and there were no other errors during the update process which has completed and updated successfully. The error you experienced relates to not being able to reload of one the active user sessions, but this should not cause any issues. Kind Regards, Dave.

@Keith Just FYI we released an update this morning (1049) which should include the fix for this issue, for some reason it has not shown in the release notes but it was included. If you still have any issues after the update then just let me know. Regards, Dave.

@Keith Oh ok, yeah thats an odd one for it to be missing from the profile, but quite likely to be the issue. I have a fix completed, so as soon as we are able we will release an update with it included. Regards Dave,

@Keith We're just working on an update for this and another defect, so there should be a new release of SM shortly which will include a fix for this. Regards, Dave.

@Keith I've identified the issue, apologies but there was a incorrect parameter being used when trying to use the default translation string for the sub-status entries in the selection list. Could you confirm that your selected session language is different to the language used for the sub-statuses? If this is the case then this would result in you falling back to the default string which is unfortunately not displayed due to the parameter issue. I'll raise a problem record for this and get the fix put in now. As a short-term workaround, if the sub-statuses have all been created under a different language to your current language setting, you could try temporarily switching your session language from the top right profile icon to that used in the sub-statuses, this should then show the translation text. Or alternatively you could also add a translation entry into each sub-status for the language that you are using. If you have any queries on this just ask. Regards, Dave.

@Keith At a quick glance it looks like its something do do with the list not being able to find the sub-status string in your selected language or a suitable default language string, I've managed to replicate when switching language so when I get the bottom of it I'll post up. Regards, Dave.

Hi Keith, The icons should be there, they have been added to show you the service icon, followed by the request type icon and then finally whether it is a running or paused sub-state... however for some reason you are missing the name of the sub-status which should be being shown before the final icon. I'll see if I can replicate the issue locally. Regards, Dave.

Hi @Martyn Houghton I believe I have a fix for this scenario, just doing some testing on it. We already have the next update (2.50) undergoing QA so I will get the fix in for the following update (2.51). Regards, Dave

Hi @Gary@ADL Thanks for the post, could you confirm which routing rule operation you are using to apply the email updates? e.g. in my screenshot I'm using "logOrUpdateIncident". In the latest version of Service Manager (2.49) we made a change to fix the scenario you have raised, however I've just taken a look at the various available operations and I'm guessing that you may be using the "updateRequest" operation which for some reason did not have the same update applied as the other "logOrUpdate" operations. I will make the same change to the "updateRequest" operation which will solve the issue in future, however it may not make it into the next update (2.50) in which case it will be available the following update (2.51) In the short term, if suitable and should you wish to, you could try using the "logOrUpdate" operation which will send the notification with the original email update content before the status update is applied. Any queries just ask. Kind Regards, Dave.