This suggestion is coming straight out of a use case that I have not found a scalable workaround for: So in the honor of this old school problem the theme of the app is in Windows 3.1 Hot dog Stand!!!
Layout you have an app that you might break off mid process (think assembly) as with this type of Job we use the Job # to track where we are in the process:
Later on the parts come in and you are able to go back in the process so you go to the start page and enter the job # and click the got to last step button ( (Trigger argument snip):
Now say you want a refresher of the previous step before this on so you click the previous button but instead of going to the previous step in the app tree it takes you back to the first step in the app
So here is the suggested improvement:
Please add in the options for step drop down:
No update on this guy yet. You can always store the last step name to a table, but this has limitations (like this approach wouldn’t work to go back 2 steps). We can make a quick demo of how that could work if you are curious.
One thing that complicates this some is step groups. Would you expect this action to go to the next step up skipping the step group or not?
What about if the step group is minimized in the editor? Effectively, these are no different, but could cause some confusion for a new user.
I think the visualization of steps in a linear order is an artifact of where Tulip evolved from as much as anything else, but its something we should provide the tooling to better leverage. I will bump the feature request and understand if there are technical reasons this is more challenging than I expect.
I believe I was the one working with the OP that led to this post/suggestion. The suggestion you make regarding saving the last step to a table is partly what causes my issue in the first place. The other example I run into is jumping to a “reference step” (such as typical torque charts, acronym definitions, fluid levels, icon definitions) which may be referenced by several steps throughout the app. Jumping to this “reference step” then back into the workflow requires that I now individually program each BACK button in the app to go to a specific step. This also limits the flexibility of rearranging the app if/when necessary.
I guess I am a little confused about your reference to the Step Group. The Go To Step NEXT trigger does not consider if the next step is in a different group or if the group is minimized in the editor. It proceeds to the next step in the step tree. So I would assume an option to Go To Step PREVIOUS should react similarly. The current function of PREVIOUS is not the inverse to the current function of NEXT. I do think both interpretations of PREVIOUS are valid however (last active step & previous step in step tree).
Is there any update on this functionality? Would be very useful to declare a “Previous” button once in the base layout rather than having to statically declare each transition for each page with a previous button.
Hey @dsun, thanks for reviving this thread. I want to tag my colleague @jakerigos into this conversation. We’re looking at work for improving the transition experience later in the year and I think this thread is a good summary of some of the difficulties folks are having with the current model. If you want to share more about your use case or if you have questions he’s a great resource.
My name is Cuyler, and I’m a Process Engineer at Agility EMS.
We’re also encountering issues with the Previous button. As it stands, it retraces the user’s navigation history rather than stepping backward within a structured step group. This behavior makes the button unreliable and unintuitive for apps that involve a main sequence with optional sub-sequences.
Proposed Solution
It would be far more useful if a Back button could reference a step group and move backward one step within that group, rather than following the exact navigation path the user took.
I’ve attached a diagram to illustrate the problem:
Red arrows show the current behavior—users are forced to backtrack along their original navigation path, which often takes them to irrelevant steps.
The intended behavior would allow users to step backward within the main process flow, ensuring logical and predictable navigation.
Implementing a step-group-scoped Back button would significantly improve workflow efficiency, especially in manufacturing environments where structured sequences are critical.
Let me know if I can provide any additional details. I appreciate your attention to this issue, as it has been a long-standing pain point for many users over the years. Hoping to see a solution soon!
I see your point, but disagree with your solution (or I got you a bit wrong).
The sketched use case would be easy solved, If you could simply have a switch on the step settings to exclude it from the navigation. This would be useful for any prompts, or settings pages or so…
I have some non linear apps, and there the only logical previous navigation is to go back the way you came (excluding modals etc.)
An exclusion toggle is a possible solution, but I believe that allowing app builders to decide what group of steps they want their back button to follow allows for more customization. If this were to be added, I would also like to have the option to use the original previous button navigation style of following the users previous path.
Although, if both of our recommendations were implemented, that would be amazing.
