Darren KIng Posted October 9, 2017 Share Posted October 9, 2017 Hi all, I'm having a problem with setting SLAs based on priority and teams - not sure if it's me or the system.... Here's what I'm trying to do... We have two teams - the services team and the applications team. We work on different types of issues and have different SLAs to resolve them. To build this functionality in Hornbill I built a corporate SLA called Incident SLA. Against this I added two SLAs - Standard (Apps) and Standard (Services) and added appropriate response and resolution times. I then created a rule called Standards (Apps) which had the following under all conditions must match Priority is standard Team is IT Applications I then created a second rule called Standard (Services) and created a similar rule but filtered on the other team. I updated the business process and added the start timers for the SLA along with an SLA update request (Automated Tasks -> Entity -> Requests -> Update Request -> Service Level). There are existing conditions which means this step only run after a priority and owner is assigned. And then I tested.... I ended up with a incident log using Incident SLA but the exact SLA hadn't been selected. After testing various bits I put another SLA on called 'Catch All' and add a rule saying 'Priority is Standard' but with no team requirement and put this rule at the bottom of the list. Tested again and my incident log now has the 'Catch All' SLA. This implies that the team that the call is assigned to is not being passed to the rules to determine which SLA should be assigned... ...or that I'm doing something wrong. Any help would be appreciated. Thanks, Darren Link to comment Share on other sites More sharing options...
James Ainsworth Posted October 9, 2017 Share Posted October 9, 2017 Hi Darren, Thanks for your post. I would be interested to know where you created your rules? There are two levels of rules that are available. One level is to select the Service Level Agreement (SLA) when you have more than one Service Level Agreement (SLA). Then, within each Service Level Agreement(SLA) if you have more than one Service Level (SL), another set of rules is available to choose between the Service Levels (SL). Here is an example of a Service with multiple Service Level Agreements (SLA). The Manage Rules option here becomes available when there are more than one SLA associated to the Service. If no rules are set, it will always take the first SLA. A second set of rules can be configured under each SLA when there is more than one Service Level to choose from for an individual SLA. Once you have more than one Service Level under a SLA, you must create rules to apply these. If no rules are added, the first Service Level will always be applied. Let us know if this is helps with your configuration or if you have rules set up as above and you are still experiencing issues. Regards, James Link to comment Share on other sites More sharing options...
James Ainsworth Posted October 10, 2017 Share Posted October 10, 2017 Hi Darren, Here is a video that also take one through the SLA and Service Level configuration... Link to comment Share on other sites More sharing options...
Guest Posted October 10, 2017 Share Posted October 10, 2017 Hi @Darren KIng I think I may have replicated your scenario and I am getting a similar result. Leave it with us to investigate and we'll be back shortly. Kind Regards Bob Link to comment Share on other sites More sharing options...
Darren KIng Posted October 10, 2017 Author Share Posted October 10, 2017 Thanks @James Ainsworth and @Bob Dickinson, Just to confirm... Initially I tried to create two sets of SLAs ('Applications Team SLA' and 'Services Team SLA') and then link them both to the service and then built the rules based on the team so Hornbill knew which set of SLAs to use. That didn't work and no SLA was assigned to the call log at all. Then I tried setting up one SLA with all the service levels for both teams and matching the teams within the SLA (as per the method above). Glad you managed to replicate the problem and it's not just me Thanks, Darren Link to comment Share on other sites More sharing options...
Guest Posted October 10, 2017 Share Posted October 10, 2017 Thanks for the update @Darren KIng Our developers have taken a closer look at this and confirmed that its a defect - it appears that the Team criteria in the rules is not being picked up, which is why it defaults to your "Catch All" every time. We will be working to resolve this and release the fix in an upcoming release - I'll keep you up to date with the progress so you will no when to try again. The issue you have mentioned with two sets of SLAs may well be related if you didn't have a catch all SLA to pick up as nothing would have matched during the decision process. Kind Regards Bob Link to comment Share on other sites More sharing options...
James Ainsworth Posted October 11, 2017 Share Posted October 11, 2017 Hi @Darren KIng The development team have completed the work to resolve this issue. This will be delivered in then next Service Manager update which should be available next week. Regards, James Link to comment Share on other sites More sharing options...
Guest Posted October 16, 2017 Share Posted October 16, 2017 Hi @Darren KIng Service Manager Update 1073 is now available - this contains the fix to the issue you posted here. If you would like to apply the update to your instance and try your SLA again (with the team criteria in the rules), it should now work as expected. Please let us know if there are any issues. Kind Regards Bob Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now