Timothy Russ

For any ticket that misbehaved due to a unintended stop, it would be the last action/trigger in the list, unlike other bad triggers that can occur anywhere in the chain and have to be hunted down.

That's what brought me to this thread: a ticket went through one of *many* rules, was re-assigned in an undesirable manner and - even though I could tell which trigger did it - the only option I have to correct it without a "stop processing" action is to hunt through a large number of triggers and modify an unknown number of them to get the behavior I need. Or put in another trigger that relies on the existing undesirable behavior and corrects it, risking misbehavior if any of the related triggers are changed later.

Not having the basic logic structure of a break forces many to implement this "house of cards" rule structure where any failure to process in the intended manner can lead to a cascade failure. The severity of stopping before you expect versus continuing to process with bad data is dependent on your particular triggers and their actions - for some the former would be terrible, for others it would be the latter, for others still the impact would barely be noticed.

If a rule that "stops" is particularly risky for your implementation then I wouldn't fault you for not using it - but it's a straightforward functionality that would allow a tremendous simplification of many trigger sets, making the logical flow more intuitive, more efficient and easier to modify/manage. It's depressing the number of hours spent on creating and fudging triggers that, in retrospect, would not have been needed at all with this functionality.

Having said that, I totally agree that adding a "Trigger Processing Stopped" action in the event view would be great for identifying when a stop occurs. Given how the current trigger actions log that seems like it would be the behavior we could expect by default.

Nothing will stop the misuse or creation of bad triggers, with or without this feature, and if it did stop a ticket from triggering as expected it would be easier to locate and troubleshoot than most existing trigger actions. It would also seem that editing a bunch of existing triggers to add an exclusion would be even more prone to creating difficult to find trigger errors.

I agree that a cascading trigger execution is an intuitive default behavior but a simple change like this drastically simplify it's operation for those that would use it and be of no consequence to those that don't. It stands in for the exact process you're suggesting as an alternative while being easier to implement, change and troubleshoot.

While it may be possible to write your triggers in such a way that you can avoid these conflicts, I very much agree that adding this option has the potential to avoid the need to reconfigure every other rule to accommodate an otherwise simple change.

I'm actually very surprised it isn't already there.