SLA Start Condition - Group List

knight202
Kilo Guru

Hello,

I'm trying to use Group List from the incident table as a start condition for users within a certain group (see screenshot below). For some reason, the SLA will not attach. Does anyone know what the Group List field is used for? My impression is that it is the groups a certain user is a member of.

find_real_file.png

1 ACCEPTED SOLUTION

Interesting challenge, and although it sounds like a fairly common scenario I can't see an obvious way of doing it.



Instead, my approach would be:


  1. have a script action as a response to the incident.inserted event
  2. have this script interrogate the groups the individual belongs to
  3. attach the customer-based SLA to this incident if isMemberOf() revels them to belong to the VIP group


It's a bit of a convoluted way of doing it.   A business rule may be cleaner, but either way it sounds like some scripting is needed to check the group level.



An alternative way is - if you're not using the VIP flag - to have a business rule that bestows this flag upon them joining the group (and removal when they leave the group) so that every member of the VIP group also has the VIP flag against the as a user. The SLA can then use this user condition to trigger the customer-based SLA.   That's kinda the purpose of the VIP flag, but it's not extensible enough to cater for more than one group/SLA combination.



Does that help at all?   It seems strange that there's no standard way of doing it (at least, not that I can see)


View solution in original post

12 REPLIES 12

If it's a VIP user, that's fairly easy.   If it's a condition where that user happens to belong to a specific group, that's a different matter, since they could belong to several groups.



Are all members of this "VIP group" actually VIP users?   Is there only the one "VIP group"?  



I've a feeling you're looking at creating customer-based SLAs where the targets differ from "normal" SLAs due to their status (or rather, due to the business impact with their loss of service). If this is the case, I may have a solution.


Correct. Customer-based SLAs where the sole start condition would be the specific user group they are a member of. Any ideas?


Yes, but it's going to need some scripting on the start condition.



Similarly, your design needs to consider membership of multiple groups - unless it's a singleton situation (only one SLA for a particular group membership), i.e.:


  • incident for group A members triggers SLA_a
  • incident for group B members triggers SLA_b

.. can someone exist in both groups, and if so - which SLA fires?


Here's an example:



Person A is a member of the following groups:



Group A


Group B


Group C


Group VIP



Start Condition should be:



If user is a member of Group VIP is true.


Interesting challenge, and although it sounds like a fairly common scenario I can't see an obvious way of doing it.



Instead, my approach would be:


  1. have a script action as a response to the incident.inserted event
  2. have this script interrogate the groups the individual belongs to
  3. attach the customer-based SLA to this incident if isMemberOf() revels them to belong to the VIP group


It's a bit of a convoluted way of doing it.   A business rule may be cleaner, but either way it sounds like some scripting is needed to check the group level.



An alternative way is - if you're not using the VIP flag - to have a business rule that bestows this flag upon them joining the group (and removal when they leave the group) so that every member of the VIP group also has the VIP flag against the as a user. The SLA can then use this user condition to trigger the customer-based SLA.   That's kinda the purpose of the VIP flag, but it's not extensible enough to cater for more than one group/SLA combination.



Does that help at all?   It seems strange that there's no standard way of doing it (at least, not that I can see)