Order of SLA policies | Community
Skip to main content

Order of SLA policies

  • October 26, 2022
  • 6 replies
  • 0 views
Haley11

Hi there, dear community!

I have learned that orders of SLA policies are important.

'Order your policies from the most restrictive at the top to the least restrictive at the bottom'

 

Questions: 

I have created 3 SLA policies, but each one is not related to one another.

It is each department's individual SLA.

(= each department's First Reply Time target differs. As it is run by different standards)

 

Would that still work even though SLA policies are not relevant to each other?

Currently, I am using 3 brands. As long as I have set "Brand is A/B/C" in condition, would SLA work without an issue?

 

Any input would be appreciated!

Thank you~!

    6 replies

    Jacob20
    • Jacob20
    • October 26, 2022

    Hi Jiyoon,
    It sounds like you should be fine with your setup.
    The directions about ordering policies from most to least restrictive, is because the conditions are being checked on the top policy first, and if a ticket matches it, none of the other policies would be checked. So if you had started with a very unrestricted policy, a more restrictive policy later on the list may never be considered.

    But since you appear to have equal levels of restriction, and no overlap in conditions you should be fine. You may want to consider having a catch-all or fallback policy at the bottom to catch any tickets that don't match the policies you already have.

    Hope that helps!

    Haley11
    • Haley11
    • Author
    • October 26, 2022

    Hi Jacob. @jacob20

    Highly appreciated for your help!

    Well noted that it should be find as the 3 Brands appear to have equal levels of restriction.

    However, I wanted to check about a catch-all or fallback policy you mentioned.

    How may I set the policy at the bottom?! Could you elaborate a little more?

    Jacob20
    • Jacob20
    • October 26, 2022

    Sure thing.

    So if your main policies cover Brand A, Brand B, and Brand C, you could have a single fallback policy with the conditions:

    Is not Brand A, and
    Is not Brand B, and
    Is not Brand C.

    This should catch anything that falls through the cracks, and if you create a Brand D, those tickets will also have the fallback policy applied.

    Hope that makes sense.

      Haley11
      • Haley11
      • Author
      • October 26, 2022

      Hi hi great to hear from you!
      Thank you thank you!

      However, i am not quite sure how exactly I should set. So let's say it is Brand A setting.
      Then should I set as below?

      -Brand is A
      -Brand is not B
      -Brand is not C

      Should I set like above for setting A?

      Jacob20
      • Jacob20
      • October 27, 2022

      Hi Jiyoon,

      Sorry for not being more clear.

      So if you already have:

      • Policy A condition: Brand is Brand A
      • Policy B condition: Brand is Brand B
      • Policy C condition: Brand is Brand C

      That should be all good, there are no overlaps, so no need to exclude further.

      As an optional fallback, you could have a single policy with multiple conditions that negate the policies you have in place:

      • Fallback policy: Conditions Brand is not Brand A + Brand is not Brand B + Brand is not Brand C.
      Haley11
      • Haley11
      • Author
      • October 27, 2022

      Oooppsss my apologies.
      Would you be so kind and explain again?

      For the fallback policy, 3 brands are all excluded.
      Let's say it is Brand A.
      All I need to set is as below, no?
      1. Brand is A.
      2. Brand is not B.
      3. Brand is not C.

      Terms & ConditionsCookie settingsAccessibility statement