I want to create a cross user flow between 3 different pages on user flow 1 (say pages 1a, 1b, 1c), and a page on a different user flow 2 (say page 2). I’d like a single, context-sensitive Back button on page 2 back to the specific page the user came from (1a, 1b or 1c).
I’ve seen the video tutorial on how to create a BACK button, but this is only a single route, where in my case there are 3 possible routes. I don’t want to create 3 different BACK buttons, because that looks messy and requires the user to actively remember where they came from, which is not very user friendly.
I try to implement this using a key/value pair in a NavData table. When the user cross-navigates from 1a/1b/1c to page 2, a key “Page2BackButtonOrigin” is set with a value that refers to the specific origin page. On page 2, when the user clicks the Back button, a flow part looks up the value from “Page2BackButtonOrigin” in NavData, and uses 2 decisions to route to the correct origin page.
The following issues prevent me from getting it to work:
I can’t navigate from a flow part to a page on another user flow.
I can’t navigate from a decision to a page on another user flow. (I saw on a post from 2020 that this is a Triggre limitation, and that it was on the roadmap, but 5 years later it apparently hasn’t been implemented yet)
Hi Sjoerd,
That is an issue I’ve been struggling with too.
A solution that works for me and might work for you too is to define the atribute Page2BackButtonOrigin directly in the user data-item or any data-item that is part of the user context and than define not one, but three separate Back buttons to each of the origin pages.
On each button you place a validation, that states
User\Page2BackButtonOrigin = [page of origin]
That way, only the Back buttion with a TRUE validation will be shown to the user and that will always be only one.
Of course, the downside is that you have to use different names on the buttons, because they can;t all three be named “Back”. You’ll have to use something like “Back to page 1a”, “Back to page 1b”, etcetera in order to pull this off. But it does work.
Thanks! This is in some cases a practical workaround. However, it’s not really useful for my case. I did’t mention this context before in order to stay concise, but I’m trying to emulate subform functionality.
So I can indeed implement your solution, but when using the Back button to navigate from subform to parent form, the state of the parent from is lost. I could save the state of the parent form when the user navigates to the subform, but that requires a flow part and unfortunately Triggre won’t let me navigate to a page on another user flow after a flow part.
A solution to get exactly what I want would be to duplicate the subform on the original user flow for each parent form, but unfortunately I can’t copy pages either, so I’d have to set that up manually, which is a lot of work and feels unnecessarily complicated - and makes it hard to maintain, too.
Ah,i see. Then you need something extra indeed and I have a suggestion for that too.
What you can do is implement an Update flow part for the data-item that is changed on the parent pages (assuming these are 1a, 1b and 1c) in the user flow of the child page (assuming this is 2). Add this action as another node in the flow, accessible via a ‘submit’ button from a data page, but disable the access to the page by an always FALSE validation, like “currentDate = 01-01-1900”, so it can’t be accessed through the flow itself. Adding a dummy Condition also works (see picture). Let the exit node of the flow part point to the page 2.
Place input elements for all data you also have input elements for on the pages 1a through 1c on this ‘dummy page’. Format etc. does not matter, since no one will ever see this page. Just choose “Add multiple attributes” and select what you need from the data item, select even every attribute if you want (see picture)
Then, have all of your pages, 1a through 1c, point to the Update flow part. When you do this, Triggre will ask you for the input information, that it normally expects from the Submit button. This includes the record to update and the values submitted. Use the input on the pages of origin to fill the values. Now, your data will be saved once entering the user flow of page 2, before it shows page 2. And the dummy page needs no double maintenance, except when new values must be added.
Hope this helps, let me know if you need any clarification.
Just weighing in here with a bit of information about the development effort on this. First of all, it was a lower priority issue because of (intricate ) workarounds being available like the one @sylvester posted.
That being said, we have a feature lined up for the next release (i.e. development and testing on it are done) that allows to create a cross user flow link after a decision.
I don’t think this includes cross user flow links after a flow part just yet, but this does help in creating such cases as you describe.
Finally, as a tip perhaps for rules in user flows that are always false, I always use this:
Current user / Blocked = true
Or shorter (which is why I like this; it’s quick to make):
Current user / Blocked
Any current user can never be blocked, and as such this will always be false.
Good to hear about this new feature, that would really come in handy!
About the currentUser/Blocked option: I use that one too. However, a little minion named Eddie once pointed out to me that this will not work in either flow parts (unless you add the user to the input parameters) or automation flows and therefore it is better (i.e. more consistent) to use an impossible date in all cases. I tend to agree with him.
) workarounds being available like the one 
once pointed out to me that this will not work in either flow parts (unless you add the user to the input parameters) or automation flows and therefore it is better (i.e. more consistent) to use an impossible date in all cases. I tend to agree with him.