How to prevent additional SLAs from attaching

[ralphalberti]

Does anybody have any ideas of how I can prevent a second SLA attaching to my Incident if the Start Conditions become true a second time during the course of resolving an Incident?

Here's my situation;

1. I have two types of Resources (Onsite TSR and 3rd Party Technician) that I can Dispatch to Resolve an Incident.
2. My Stop Condition is Incident state is one of TSR Arrived Onsite or Tech Arrived Onsite.
3. If I stop the SLA by changing the Incident State to TSR Arrived onsite, the SLA completes as expected.
4. If the TSR cannot resolve the issue and I need to Dispatch a 3rd Party Technician, the SLA conditions become true again and second Task SLA attaches to the Incident which I don't want. My customer is satisfied when either of the two resources arrives onsite so there is no need to spawn this unwanted Task SLA.

Here are my Start Conditions

Here are my Stop Conditions

Thanks for any help you can provide.

Ralph Alberti

[Michael Fry1]

As you found out, anytime the Start conditions are True, it will attach. So you'll need something else to prevent the reattachment. I usually just create a new checkbox field, and use it in your start condition, where it is false. Then use a business rule to set it to true when: Incident state is one of TSR Arrived Onsite or Tech Arrived Onsite. Then if state changes, it won't reattach.

[ralphalberti]

This is a great suggestion. I will give it a try and report back here. Thanks.

--Ralph

[ralphalberti]

I added the checkbox to my Incident form and wrote the business rule and it worked perfectly. Next thing I will try is to see if I can write to the field if it isn't on the form or at least hidden.

I have an additional question if you don't mind. A developer we hired always started off his SLA defs with "Active is True". It seems he did that back in the days when we started out on Eureka because there was no way to choose whether an SLA was Active or Inactive. I don't think this is necessary anymore and would love to get your opinion.

Thanks for your help. The spawning of additional Task SLAs was nagging me for quite a while.

--Ralph

[Michael Fry1]

The reason we did/we do that is that the Start Conditions must be true for the life of the ticket. If the Start conditions start off as true but then later become not true, the SLA would cancel vs complete. Using Active = true for Start and Active = false for Stop made clear start and stop conditions with no chance of the start conditions becoming false, unless the Stop conditions are met.