# Halting Trigger Execution

**URL:** <https://community.tulip.co/t/halting-trigger-execution/3860>\
**Category:** Support, Troubleshooting, & Help\
**Created:** [October 22, 2021, 2:16pm UTC](https://community.tulip.co/t/halting-trigger-execution/3860 "2021-10-22T14:16:51Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Lance](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@Lance](https://community.tulip.co/u/Lance)\
**Post date:** [October 22, 2021, 2:16pm UTC](https://community.tulip.co/t/halting-trigger-execution/3860/1 "2021-10-22T14:16:51Z")

</div>

I have a button with several triggers associated with it. Under certain conditions (incomplete input from other step widgets) I want to avoid firing some or all of the triggers. Besides adding all the conditions to “not fire” to each trigger, is there a way for a single trigger to behave in a manner that would preclude the subsequent triggers from firing? This would allow me to make the check on whether to proceed in a single trigger that either allows or aborts the rest of the button logic.

---

<div class="post-metadata">

**Author:** ![gio](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/gio/32/82_2.png) [@gio](https://community.tulip.co/u/gio)\
**Post date:** [October 22, 2021, 2:20pm UTC](https://community.tulip.co/t/halting-trigger-execution/3860/2 "2021-10-22T14:20:04Z")

</div>

hey Lance, this is an interesting question!! I’m curious to hear what others suggest.

one way I would think about solving this is by creating a new Step, and having all your Triggers on Step Enter for that Step and then end with a Transition to return to the previous Step. on the Button click, you can define whether or not to Transition to the Step with the Triggers.

do you think this solution could work for you?? let us know!!

---

<div class="post-metadata">

**Author:** ![Lance](https://avatars.discourse-cdn.com/v4/letter/l/7ab992/32.png) [@Lance](https://community.tulip.co/u/Lance)\
**Post date:** [October 22, 2021, 5:10pm UTC](https://community.tulip.co/t/halting-trigger-execution/3860/3 "2021-10-22T17:10:16Z")

</div>

@gio Your approach certainly sounds feasible. I’ll have to play with it to see what the user experience is like for transitioning quickly to the step that performs all the logic and then back to the data entry step.  
I was wondering if I could do something similar like make the first trigger check for valid setup and if something looks wrong navigate to a temporary step that then navigates back to previous. I just wasn’t sure if that navigation would thwart the subsequent triggers from firing. I’ll play around a bit. Thanks!

---

<div class="post-metadata">

**Author:** ![gio](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/gio/32/82_2.png) [@gio](https://community.tulip.co/u/gio)\
**Post date:** [October 22, 2021, 5:28pm UTC](https://community.tulip.co/t/halting-trigger-execution/3860/4 "2021-10-22T17:28:13Z")

</div>

OK, thanks for the update @Lance.

> [@Lance](#):
>
> I just wasn’t sure if that navigation would thwart the subsequent triggers from firing.

it shouldn’t thwart subsequent Triggers. this example that @freedman shared makes use of this technique actually: [Quick tips - Looping!](https://community.tulip.co/t/quick-tips-looping/3735)

let us know how testing goes!!

---

<div class="post-metadata">

**Author:** ![sebme](https://avatars.discourse-cdn.com/v4/letter/s/439d5e/32.png) [@sebme](https://community.tulip.co/u/sebme)\
**Post date:** [January 25, 2023, 9:30am UTC](https://community.tulip.co/t/halting-trigger-execution/3860/5 "2023-01-25T09:30:56Z")

</div>

Just came across the very same problem… except that in my case I am not able to just add yet another step… there are already too many…

I am also looking for a way to just stop any further execution and basically halt at the step that is causing the exception… 😐 …ideally coupled with a stationary error that does not just disappear by itself like the error messages that are currently available.

---

<div class="post-metadata">

**Author:** ![thorsten.langner](https://avatars.discourse-cdn.com/v4/letter/t/4bbf92/32.png) [@thorsten.langner](https://community.tulip.co/u/thorsten.langner)\
**Post date:** [January 25, 2023, 11:02am UTC](https://community.tulip.co/t/halting-trigger-execution/3860/6 "2023-01-25T11:02:25Z")

</div>

Hi @sebme,

you could create a boolean variable called “valid” or something.  
At each step you enter, you do a cleanup trigger that clears some values and sets some defaults and so on. One of the defaults is that you set the variable “valid” = true.

Whenever an if statement decides that an input is invalid or missing, the variable “valid” must be set to false.

All dependent triggers check for “If valid = true” as a condition.  
The last trigger contains a message if valid = false.

I hope this helps.  
It may seem complicated, but it is actually simple and easy to implement.

---

<div class="post-metadata">

**Author:** ![sebme](https://avatars.discourse-cdn.com/v4/letter/s/439d5e/32.png) [@sebme](https://community.tulip.co/u/sebme)\
**Post date:** [January 25, 2023, 11:07am UTC](https://community.tulip.co/t/halting-trigger-execution/3860/7 "2023-01-25T11:07:34Z")

</div>

Sure… but all this overhead just to halt execution? You have to introduce a trash variable. You need to add additional condition blocks…

As complexity of you app grows you have a lot of fun keeping things lining up…

---

<div class="post-metadata">

**Author:** ![thorsten.langner](https://avatars.discourse-cdn.com/v4/letter/t/4bbf92/32.png) [@thorsten.langner](https://community.tulip.co/u/thorsten.langner)\
**Post date:** [January 25, 2023, 11:23am UTC](https://community.tulip.co/t/halting-trigger-execution/3860/8 "2023-01-25T11:23:54Z")

</div>

The alternative is checking all conditions in every single trigger.  
What is your vision of an easyer solution?

If you need a better solution, you could make a product suggestion to make an error message with an interrupt resulting in stopping all triggers from there on. Or an overriding condition that triggers are executed at all.  
This would be possible but would not allow anything else to happen.  
So the only solution to completely reach this is to allow **trigger nesting** (a trigger activating a group of triggers) thats exactly what happens with new steps. There is also an easy workaround with one additional step and one variable.

If we are talking about a product suggestion like this, you could choose one way you like and suggest it.
