Is there any plan to add a “Reload Current Step” transition?
I have several applications where I want to do a data verification before performing several other triggers based on valid form inputs.
The best way I understand to not process any remaining triggers if the information is not valid is to have a verification check on the first trigger and if it doesn’t pass the verification then show an error and put a transition Go To Step → Current Step Name. This cancels any remaining triggers from firing.
If this is a common step that works OK when copying and pasting from one app to another after making an update, but I have lots of steps that share the logic but have different names.
It would be much easier to have some kind of Reload Current Step transition, that would function the same as Go To Step → Current Step Name. This could be copied and pasted without needed to change the name of the step every time.
@steve.midcalf this is a great suggestion! and definitely something that I’ve thought about myself.
The Product team is aware of this and has some work underway, but when I was thinking about this I had a different idea. There is the “Stop Remaining Triggers on Error” option that appears in the top-right of your triggers queue; if you force an error, you’re able to essentially break your triggers flow and get them all to stop.
Now, how to force the error is the interesting part. When I was discussing this internally I came up with two possible options:
Give a driver a bad input - for example, input an invalid IP to the Zebra Network Printer driver
Attempt to use the Expression 1/(1-1) - explicitly dividing by 0 is not allowed by the Expression Editor, but this is!
Other suggestions include attempting to index into a blank array, or do a bad casting like using TEXTTOBOOLEAN() with the invalid text test
I never tried the Show Error Trigger Function, I kinda doubt it but perhaps that would work too…
Unfortunately, I can’t usually use the stop remaining triggers on error option for this application. The button has several triggers that go to different data sources (setting variables in the app, writing to a Tulip Table, sending a bit to the PLC, emailing and texting users, etc.) If any one of them fails I still want the others to process.
The Show Error action will not cause an error, it’s just showing a message with a red background instead of the yellow background with Show Message.
Like I said in the original post, the transition to current step works fine. It would just be nice to make it a restart step transition instead of having to give it the specific name of the step.
Another workaround you could use, which avoids having to individually modify the “current step name” issue, is to run a trigger on enter that stores the current step name (this should be done on all steps); then you can go to step by name and use that variable, or table record, wherever you decide to store that step name.
@RDuke thanks for the suggestion! that’s a great way to workaround. looks like both table records and variables get created and come over when copying the step from one app to another so either method works. I personally prefer a local variable instead of having to use a record placeholder.
Have you figured out how to use this for navigating to the step from base layout? Every time I copy and paste I have to delete the old step first and then paste the new step in after making a change. But when I do, the button that navigates to the step shows Go To Step ->Deleted Step and I have to change it to the new step name. Would there be a way to populate the step name in a table so that it wouldn’t have to be changed in the transition from the base layout button?
If I’ve understood the need, you could have a transition step that runs a trigger on enter - then that step could have logic within to decide if it go’s to ‘previous’ step or onwards on your path if criteria are met?
Still a little clumsier than a reload, but a potential reusable workaround.
As @RDuke pointed out earlier, the best workaround for this is to add an On Step Enter trigger to the Base Layout to update a Current Step Name variable
Then for any of the validation triggers that you need to restart the step if the conditions are not met, use the transition Go To Step By Name → Variable → Current Step Name.
Place this as the first trigger and it will prevent any other triggers from firing if the validation criteria fails.
When you have to copy the Base Layout Trigger and the Reload Trigger itself, you have to copy two things anyways.
Isn’t it an option to make a blank jumper step on step enter -> got to step -> previous
And the Reload trigger is only a transition to this step?
I guess this is:
Hopefully I am not misunderstanding the OP’s issue. It wasn’t stated if there were “On Step Enter” triggers or other reasons to reload the step. If it is not necessary to reload the step, what I have done in the past is use a boolean bit to control my triggers. So “On Step Enter” and/or my first trigger would set the bit (I usually call it Can_Proceed, or similar) to FALSE. Then as I go through my triggers I would toggle it to TRUE when I have passed my data verifications. The triggers following the data verifications would have a condition checking for IF Can_Proceed = TRUE, THEN complete actions, otherwise no action is performed on the trigger. This seems to Copy/Paste between steps and apps fairly well. Just have to make sure any new triggers are looking for this bit, if necessary. If I need to show custom error handling messages I will often setup my last trigger to look for IF Can_Proceed = FALSE.
One benefit to this method is you haven’t reloaded the step which can potentially ruin “Go To Step > Previous” triggers.
I do see significant value for the “Reload Current Step” transition though. It would be a big help for looping actions.
I guess this method is known to the OP, but does not fulfill the requirement of copy-pastability.
You have to manually implement the change of the Value of the Variable and you additionally have to reset it. Adding a transition at the end as an “else” seems easier.
You are right, that you have to be careful with your on step enter triggers.
I want to mention some other things you could keep in mind:
If you use a Boolean variable for data validation, it is more practical to set it to “true” initially and set it to false in case of interrupt. Otherwise you would set it to true after the first trigger but have to set it back to false if another trigger (checking a result of the first one calling a connector function) delivers a reason for it. It’s easy to loose track when changing triggers.
Always start with true and if it becomes false on any point, it stays false.
Using the “Can_Proceed” variable (i call it “valid”) is fine to only stop the transition. But if you want to stop executing following triggers, its an additional afford, since you have to check against it manually in every single trigger. This is relevant especially if you run multiple triggers that depend on the result of a connector function. (If the result is not valid, you can not manipulate it as expected and not throw it to the next connector function…)
“Go To Step > Previous” triggers will not be ruined, from reloading a step. Not by directly reloading it, and not by doing it with a jumper step
What you also can consider:
Making a calculation step
If inputs are fine, transition to that step
when not valid in between calculations → previous (will stop further calculations)
when done transition to next step
The downside is, that its only appropriate for bigger calculations (exceptions) because you don’t want to have 34 Steps + 34 Calculation steps…
I usualy use a mixture of all three attempts, depending on the actual use case.
Easy copy/paste is a critical requirement for me. I have several steps that are common amongst multiple apps.
If I make a change to one of those common steps and then have to copy and paste it to 90+ apps, I don’t want to have to make multiple modifications in each and every app after pasting the updated common step before publishing the new version of the app.
The 3 challenges I had prior to my original post were:
• Reloading the step required a step name that got lost on copy/paste
○ This was solved by adding a variable Current Step Name that gets updated on each step enter (adding on enter step trigger to base layout)
○ This way any step that uses form validation when a button is pressed and reloads the current step to cancel any subsequent triggers if the validation fails doesn’t require modifying the step name to reload
• Navigation to the common step from the base layout would change to Deleted Step when the old step was deleted
○ This was solved by changing the navigation to the step on the base layout button trigger from Go To Step → Step Name to Go To Step By Name → Static Value → Name of Common Step
• Losing aggregation assignments in drop downs.
○ Still have this issue, any single select with a Tulip Table Aggregation Options data source loses the defined aggregation when the step is copied and pasted into a new app
○ No known way to solve this currently, will have to wait to see if Tulip can fix this
○ But since I have to visit the app to publish a new version anyway, loading this step and fixing the aggregation before publishing is not too much of a time waster.
Thanks everyone for the discussion and ideas around this topic!
You can call the aggregation via connector function (table api). Then you don’t have to implement the aggregation in the apps itself. However, you have to implement the call of the connector function in the apps (e.g. on step enter or so). I’m not sure if this is easier in your case. It depends on the actual use case.
