There is no way to copy entire trigger between to types of objects, for example from step on enter event to a button widget.
If I created a trigger in the step enter event and than I have to create the same logic on a button click event, it can’t be copied, I have to open another window and manual copy command after command, very furstrating.
For example, I created a trigger that inital value of a step (for some variable clear them, for other, gives default value that is suit for this step only), at first I put it in on step enter event, than got the idea to add a button for initial the screen, so …
Please think how to resolve this issue.
Hi Amit, I don’t have a delivery date for this, but I’m actively working on this. The use case you described is very helpful.
Thank you for notify me about that, have a great day
Is this still being worked on as its very frustrating?
Hi @SNash- Yes, we are looking at this now! Out of curiosity - are there any triggers you find yourself copying again and again?
My use case is very similar to the original poster. I have a button with around 10 triggers on (some quite detailed) and it turns out that I would like to move most of them into an ‘On Step Enter’ trigger on another page. Iv had quite a few instances where iv wanted to move triggers between different trigger types, some have been a quick to replicate but some have taken quite a while. Also, if you have to manually copy them across and the triggers are quite complex, then you also run the risk of getting the detail wrong and breaking the app. Copy and paste is always the safer option
As this was actively being looked into 6 months ago and is now being looked at again, do you have any expected delivery date? Although im sure it is complicated to implement, it feels like standard functionality that users would make use of.
Hi @SNash Thanks for following up, sorry for the delayed response. We are planning a series of improvements for how triggers are created and managed - with this request being one of them. We are excited to rollout these changes, but this specific request is delayed as a result. Best guess is middle of the year. In the meantime, would you be interested in talking more about triggers? If so, please use this link to schedule a call.
cant wait for this feature… this will save so much time.
my use case is also to copy triggers from button to step enter.
Is there any update to this topic?
I’ve go a similiar problem: I’m maintaining some apps, that run several triggers one after another which are assigned to a button. One of these apps runs 24 triggers with a single button widget - some triggers are rather simple, some very complex. As this app was updated several times over the last two years the same button is used in a few different steps and after the release of r236 the triggers were also copied to input widgets. Unfortunately this makes maintaining and updating apps a pain as I have to look through tons of copied triggers.
I would like to simplify these apps by copying the affected trigger-functions to an own “execute” step as on step enter triggers. This way I could simplify all the buttons and input widgets. The widgets will then only go to the “execute” step and the last trigger would then go back to the previous step. This way those apps would be much leaner and easier to maintain.
Hey @Alex -
Not a ton of movement on this one yet (at least not directly). We did enable the ability to change the
when type for step and app level triggers to streamline some copying, but haven’t yet extended that to
widget trigger > step trigger.
In the past ~6 months, a team has been working on a slightly new, but significantly more powerful, trigger experience to help address some of the reusability pain points that exist in triggers. The ‘more powerful’ part of this new experience has mandated some engineering work on the backend, but that is nearing a v1 state. This work should go into alpha and beta testing in the back half of this year and should see the broader Tulip world sometime in early 2023. Reusability is a first order priority of this work.