Incident Response SLA re-starts on re-assignment

[rlegters]

We've got some incident response SLAs that are causing problems. The start condition for each is "Priority is priority" and "Service(u_service) is SAP". The Stop condition is "Assigned to is not Empty". So far, so good: The SLA starts and when someone sets 'Assigned to' to a person it's complete. The problem comes when we re-assign the Incident to another group. The 'Assigned to' is now empty, but the start conditions are still true, so the SLA starts again. These are set to 'Retroactive Start', so if, by chance, they've waited past the response SLA time to re-assign, that SLA is instantly in breach.
I can't find a field on the Incdient to add to the start condition that says in effect 'we've already dealt with the response SLA on this one, don't check again.' I tried using 'Reassignment Count = 0', but then if we re-assign the ticket to another group without assigning to an individual, the SLA is just cancelled.

[rlegters]

Thanks! The business rule is firing now. It's set to before update. I also yesterday found that the 'checked' value for a true/false field is 1, so now I'm setting the responded to the correct value and using the correct condition. On to the second part - getting the SLA to see that 'Responded' is set, which shouldn't be nearly as hard. 🙂

[kevinfrost471]

Sorry to jump in late here but we were having the same problem.   We only wanted our Response SLA to fire on the fist assignment to an engineer.   We are calling the incident responded too once it got to an engineer.   We leave the incident in a New state from creation through being assigned to a group.   Only when it gets assigned to a person (assigned to changes and assigned to is not empty) does the Response SLA stop.     We added the condition of "and Incident state is New" to the start condition to eliminate the SLA from attaching every time the assigned to changed as once it was assigned it was in a state called "Active" in the field.