similar to the variable editor I would like to have a global trigger editor in which I can define triggers and use the trigger anywhere in the application. Additionally, I would like to see in which element I used which trigger.
My current workaround is to separate each trigger into reusable chunks and copy/paste the trigger into every element where I want to use the trigger. This is cumbersome and error-prone, because I have to copy/paste the trigger every time I change a part of the trigger.
Thank you for the suggestion - just to make sure I understand your suggestion, you’d like to have a trigger that you can put anywhere. When you are modifying this global trigger, you’d like to see every widget and step that it is present?
my point is: I don’t like to copy and paste triggers I use several times within one application. I would like to have a central editor to view and edit all triggers within an application. This way, a change to a trigger automatically takes effect in all elements in which I use the trigger.
In the end, my suggestion aims at a possibility to define functions globally for each app and only call these functions instead of copying them each time.
I’m sure there was a lot of discussion around this topic in several threads.
E.g.:
only global triggers could lead to some other issues.
However the Idea came up several times to just call existing triggers.
In my opinion you would need a trigger library, where triggers can be stored on app level or step level and just get called from wherever you are.
This would solve many issues.
One simple example:
I have a Text Input and want to provide some data get by a connector function.
Ways to input the text and execute the function:
Barcode Scanner (hardware)
Barcode Scanner (Optical)
Text Input Widget + Enter Key
Text Input Widget + Button Press
To achieve this I have to build the exact same trigger 4 times and can only copy it once…
Now I get the Idea to Map_to_Text_List three of the fields, to provide a dropdown for each.
I then have to update all four triggers manually and add three actions each (12 actions)
I had a similar case, where I had to map tons of object fields to a record placeholder… to do so in more than one trigger is a real pain…
I hope that helps to understand some use cases a bit…
Hi all,
I’m using inside a step a previous tip from @thorsten.langner and use the Delay-Widget for these cases.
The brilliant thing is, that I can call this widget from all other widgets of the step, where I can’t copy the triggers from.
The logic to react is only inside this widget.
yes, for me it would be fine if the triggers are scoped to each application. In my case the triggers are always a bit different in each application. Mostly, due to varying data models. So, currently I have no need for triggers that are shared across applications.
Until now I didn’t copy steps across applications. The applications don’t have that much in common. Hence, I have to change quite a lot if I copy steps.
It’s not perfect but you can start to perform this by creating a trigger table, and having an automation that runs whenever a record gets added to that table.
For example, if you had a repetitive trigger that took inputs A, B, C and did X, Y, Z in many different apps. You could consolidate this to a Create Record trigger with columns A, B, C and then have the Automation perform X, Y, and Z whenever a record gets created in the trigger table.
Hi all - @danielpomeranz is right that in the short term, you could use Automations to run repeated logic via a Table handoff. Automations run asynchronously in the cloud, and are a powerful solution to both separate out business logic and “automate” your shop floor.
However great news @jacek.kos that we are working on making reusable logic much easier in Apps. In the next few quarters, our team will begin a new project called Functions, which are reusable App Triggers, that you could invoke from an App.
An early sketch of how we’re thinking about Functions:
A Function would be reusable app trigger logic - effectively a trigger or a group of triggers, which you could build once, and call from any app
Functions would be Workspace scoped, and run synchronously in your App Trigger Queue
We’re planning to have the Functions editor be very similar to Automations. So any Automation you have today for repeated business logic should be easy to move to an App Function once that feature comes out.
We’re still figuring out exact timing for Functions and which trigger types to cover in a first release. We’re hoping to have at least a sandbox up in the next few months with a wider release later in the year, and would start with the core trigger types like math operations and Table interaction. Exact timing would of course depend on our annual planning which begins in January and other projects.
Let me know if you’re interested in finding out more, and possibly being an early evaluator of a Sandbox preview!