Stop additional rules after conditions are met

Yes, and please.

Absolutely agree with the OP, there's a real need to update the Trigger mechanism to prevent the possibility of other processing triggers being applied once a specific one is done.

I should be able to say "Once you've done all of this, don't do anything else - ever, otherwise my day as an Admin might be painful if someone else has written a bad trigger which I have to spend ages hunting down to correct".

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.

This might be the unpopular opinion, but I'd vote against the addition of this feature.

Imagine this feature existed and now one of your admins makes a trigger and places it high in your execution order and sets this 'Stop = True' feature on. Does this now mean that potentially all your tickets are cut off from triggers on updates, if the conditions are met on this early trigger? Today, triggers iterate through in a clearly defined way. The fact that they can waterfall and trigger each other is their strength, IMO. Having one trigger make a blanket execution decision for all other subsequent triggers is risky, IMO.

Triggers can currently be written in a way that they add a condition that prevents future triggers from firing, for example by adding an 'already_fired' tag and then you can add a requirement that the ticket does *not* have this tag to execute. 

This might sound like semantics, but would be better to manage having each trigger have its own conditions for executing, rather than relying on another trigger to make a one-time decision to suspend all future triggers. 

If there's other admins that write bad triggers, I don't think the solution is to change the product in this case (do you really want these admins misusing a 'stop all triggers' action?), but instead to either better train or reduce the number of users with admin access.

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.

It would definitely simplify things, I can't argue that point. I think it would also greatly increases the risk to break a lot more things if you have a bad trigger. In the current system, you can still definitely have similar problems, and it's tedious to edit each trigger, but you have that degree of control. You can do this only block a subset of triggers from firing or all, if you wanted. Yes, it's more work, but it's harder for one action to knock over everything.

If something like this did come to be implemented, it'd be nice to have it be included with refresh of the ticket event log viewer. Being able to highlight in the log that a given trigger caused a stop event would help. Maybe a red Stopped label or similar next to the responsible trigger?

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.

I have a quick wrapper condition/action that you can put into practice currently. It is a useful concept to keep in mind when running any kind of automated actions such as these. This will also allow you some flexibility in only allowing some triggers to hit the "off switch" or also allowing you to decide which triggers do and don't follow the "off switch". With that, and proper implementation, you can avoid all of the concerns as mentioned above. 

There are two parts to the wrapper, and the first is to simply put a mandatory condition that states "Ticket must not contain the following tags (automation flag)" and then an action at the end of the trigger to add the (automation tag) to the ticket. That way, when the trigger closes, and the system re-checks all triggers, any trigger that has been configured to ignore tickets with the (automation flag) tag will not fire. This will also allow you to make triggers that will ignore the (automation flag) tag or that do not set the tag when they complete. This does add a layer of complexity to the rule architecture, however it is wildly easier to manage than to go one by one and check each trigger's conditions and actions and manage an ever growing cascade of triggers.

Based on the original use case presented, I completely agree that this should at least be an option. 

Also, I would like to see a "case" trigger, where depending on the "any" match or "case" match the action would differ. This could also lessen how many triggers are needed overall. 

Active Feature Request (please vote):

Feature Request: Allow Trigger to have a "case" condition that would change the action based on the "case" matched

I created this feature request for that very feature. Please vote and comment on it to show your support if you would like to increase the likelihood it will be implemented.

https://support.zendesk.com/hc/en-us/community/posts/360046961593-Feature-Request-Allow-Trigger-to-have-a-case-condition-that-would-change-the-action-based-on-the-case-matched

Voted for and added comment for this feature request. And BTW - The excuse to "save us from ourselves" is both disrespectful and insulting to the admins. ANY FEATURE can be used negatively.

I agree, this would be a useful feature. I'm trying to stop processing if an email comes in through an unmonitored email address.