David Hall

@Alberto M I've just checked through and we don't currently populate any variables into this confirmation, it was initially provided as a simple confirmation method with an update such as "This is an automated system message to inform you that your Hornbill request has been successfully updated". I'll raise it internally to see if we can get a change raised for that. Kind Regards, Dave

@Alberto M That setting is not new, its been in place for a long time and we haven't implemented anything that would change that setting on updates. The only thought as to why you would just start seeing these emails is that something was not working correctly prior to the update and now with the updated autoresponder scripts its calling this correctly. If you turn off the option then it should stop the emails. Regards, Dave

Hi @Alberto M @Deen beat me to it That setting should be controlling the sending of the email. Regards, Dave

Hi @Alberto M There is a new update of Service Manager that went out yesterday which included some fixes specifically around the autoresponder actions. I would suggest updating to the latest version and see whether that corrects the issue. If you still experience issues post back and we can look further. Kind Regards, Dave.

Hi @Cassie Apologies, sounds like an issue reported here which we are currently investigating. Kind Regards, Dave

Hi @DFarran I've been trying to replicate but despite having a configuration that looks to match yours I've still been unable to. We've just pushed out a new update of Service Manager today, if you could confirm whether the issue still persists in the latest update that would be appreciated, if is then I'll look at some further steps to try to replicate. Kind Regards, Dave.

Thanks @DFarran that's great. I'll investigate further and see if I can identify the issue. Kind Regards, Dave

@DFarran Thanks for the update, having reviewed the code, it should default to the "highest" visibility level permitted on the request for the user, however if no levels are found it will default to "public". Unfortunately I've not been able to recreate locally to this point, would you be able to post a screenshot/list of the servicemanager roles you have assigned to the colleague that sees this issue, I can then try to match the configuration and investigate further to see if I can pinpoint the issue. Kind Regards, Dave

Hi @lukeb When you place the request on hold, are you using the popup form e.g. If so, the setting highlighted will determine the visibility of the post, it sounds like this may be set to "Owner"? This can be set as needed by the analyst, but you can set the default value via the following application setting Kind Regards, Dave.

@DFarran Apologies missed the notification of your last post. I've just posted this on another thread with a similar discussion ... if the hold action is being performed via a sub-status change, the process should follow that it will use this value if set, if no value is set here then it should revert back to using the previously mentioned app setting. In the upcoming update of Service Manager we've made some back end updates to the operation that posts the timeline update, I've just checked it with this scenario and that is working as expected, so if there is still an issue it should be corrected in the next update > build 1805. Kind Regards, Dave

@Charlie Jones @AndyColeman Just following up on this, if the hold action is being performed via a sub-status change, do you have a visibility leveI set on the individual sub-status as per screenshot? The process should follow that it will use this value if set, if no value is set here then it should revert back to using the previously mentioned app setting. In the upcoming update of Service Manager we've made some back end updates to the operation that posts the timeline update, I've just checked it with this scenario and that is working as expected, so if there is still an issue it should be corrected in the next update > build 1805. Kind Regards, Dave.

Hi @DFarran Just wondering if you are using sub-statuses here? If so then it could be the new visibility level against the sub-statuses that is giving that setting. If you are using sub-statuses, then if you view the sub-status details you should see an option to change the default value e.g. Kind Regards, Dave

@Martyn Houghton So any calendar changes will be immediately observed by any existing timers, so if you add in an exclusion day etc then the timers would respect this and wouldn't elapse during this time. What changing the calendar won't do is alter the target times set on a request. Only when setting or changing the SLA will it recalculate the target times based on the current working time calendar configuration. Cheers, Dave.

Hi @jhiggins It looks like the ORDER BY clause is incorrectly using the entity name 'Requests' where it should be using the table name 'h_itsm_requests. If this is something you have specified manually then if you update it to read h_itsm_requests.h_resolvedby_username it should run. Kind Regards, Dave.

@John C Sorry to hear that, we've moved the category to the right panel to make it more visible on the request without scrolling and provided the action tab to set it so that there is no need to edit the form and then have a popup for selection etc. If the changes have made it in any way harder to use then we're happy to take on board feedback for future improvements. Kind Regards, Dave

Hi @Martyn Houghton So if you were to make changes to the calendar, this would not alter any existing target times etc, however if you were to update the SLA on a request then it would take any changes into account. Does that answer your question? Regards, Dave

Hi @John C In the latest update the category has now been re-positioned to the side bar and there is a new action tab for setting the category as desired. Kind Regards, Dave

What's New: New setting for changing the font of On-hold requests on the request list {CH00157323} Allow user with Manage Mailbox rights to see all mailboxes on a Service form {CH00158249} As a Service Level Manager I want additional rule criteria for SLAs {CH00146261} Create Action Item for setting the category on a request {CH00141466} Add visibility of Assets to User Profile {CH00152000} What's Fixed: Routing rule templates not including user details {PM00158720} Multiple dollar signs ($) are stripped from when the details are pushed to the timeline of a Request {PM00158408} Wiki markup date in the Summary field is not formatted in the Request page title and Requests List {PM00158134} Collaboration only users should be able to see the details of a Change they're authorising in the portal regardless of the overall app-setting {PM00158362} When viewing a Request that belongs to your staff in the My Services portal, the timeline and post box are sometimes not available {PM00158433} Cannot send notifications if a User ID contains a single quote {PM00158790} When sending an email through the Business Process, the connections filter is ignored {PM00158798} Known Errors cannot be reopened due to checking of a missing app right {PM00158372} After posting to the timeline of a Request, another request action's visibility cannot be changed to a higher value than the original posts visibility {PM00157146} Request data including summary is not shown in Request list on Service page or mobile requests view {PM00158923} When a View is deleted, the entries in shared Views are not removed automatically {PM00158946} A chart showing the number of requests grouped by Rating fails to display the rating value {PM00158951}

Hi @Adrian Simpkins Yes, changes you make to the SLA configuration will only apply to new requests or if you change the SLA on an existing request, otherwise existing SLA timers will remain intact as per the original config. Kind Regards, Dave.

Hi @davidrb84 We've identified the issue and we'll have a fix in the next service manager update (build > 1781) Kind Regards, Dave.

Hi @davidrb84 Thanks for the post. I can see the same issue here, I'll raise a problem for the dev team to investigate and address. Kind Regards, Dave

Hi @Ann-MarieHolloway I've just double checked this out myself and all looks to be working correctly for me on multiple browsers. If you do find a general issue please post back. Kind Regards, Dave

Hi @Jeremy Just FYI, an overview of the service levels can be found here https://wiki.hornbill.com/index.php/Service_Level_Agreements In answer to your question, the SLTs are service based... so on the relevant services for those teams, you can configure the SLA/SL rules to pick a specific SLA/SL based on a combination of request criteria e.g. the team and priority in your case. If you configure your BPM to start the timers once your team priority have been set, then the rules will process against the criteria and set the SLT accordingly. Here is a screenshot of a quick mockup, so on SLA details in this example I have created 3 service levels (1,2,3) each of which can have their own response/fix times. I then have multiple rules defined, in this example if 2nd line support and High priority are set on the request it would pick SL 1, if assigned to 3rd Line support and High priority you will get SL 2 etc. Hope that makes sense but please feel free to ask if I still haven't answered your question exactly. Regards, Dave.

Hi @Martyn Houghton It will be a Service Manager update. Cheers, Dave.

Hi @Jeremy We already have an update with the fix in beta testing which we are about to push live so it should be available for you this afternoon. Regards, Dave.