Building a ‘Direct Screen Access’ Flow
Sometimes the user requirement calls for the person running the flow to be able to hop between screens at will, moving from any screen to any other screen. Our general advice has always been: you can do it but you need to built a navigtional button bar that looks something like a path component. I finally found some time to build one that can simply be installed as a package.
Here’s a flow screen that makes use of this DirectNavigationHeader component:
Here’s a video explanation:
Clicking on any of the path chevrons at the top takes the user directly to the target screen. This is done using a central Decision element that serves as a router each time a screen transitions:
As you can see, the entire flow has to be designed around this navigation partner, with each screen transitioning to the same routing Decision.
How It Works
Building a Direct Screen Access flow requires several elements:
- You need a navigational button bar that displays all of the screens that can be targeted. When the user clicks on a button, the button bar triggers an immediate forward transition.
- You need a decision element in your flow that acts as a central routing hub. Every screen routes to this Decision element, and the Decision element uses the information provided by the button bar to determine which screen to route to next.
- (Optional) If you want to let users navigate the ‘normal’ way with Next and Previous buttons, you need to provide them via a custom footer (essentially a second custom button bar), so that the user gets the right behavior when they click Next or Previous (because navigation is handled by that central Decision element, you need to ‘pack’ the Next or Previous clicks with target information that the Decision element knows how to use)
Here’s a look at one of the screens from the demo flow above. You can see I’ve added the directNavigationHeader on top and the directNavigationFooter on the bottom:
The above property editor is for the header component. The upper red section shows the two options for providing labels to the visual button bar. You can provide a simple comma-separated list, as shown here, or a string collection. These labels will be visible and will also be the values passed out of the component when the user transitions. The selected value (the one the user clicked on) is output as the ‘Selected Target’. In the example above, you can see that I have created a manual string variable called targetLabel to store the Selected Target. This is necessary because you’re going to have these directNavigationHeaders in each of your screens, and they all have to set the same single variable, because the Decision element is going to need a single thing that it can check.
Here’s the check that’s done:
Because each of the screens updates the same targetLabel variable, the job of the decision element is simple. It checks the value and routes the flow to the appropriate Outcome path. This scales to effectively any number of screens.
You don’t need to have a Next/Previous navigation at the bottom of the screens, because these header components are doing all the work. However, if you want Next and Previous, use the included directNavigationFooter. As described above, it replicates the Next and Previous buttons but allows the navigation to be stored in the same targetLabel value. Here’s an example:
The two fields shown in red allow the Next and Previous targets to be hard-coded, which is usually what you want if you have a standard linear pathway and just want to provide an optional direct access.
Install
Version 1.0.0 Unmanaged 1/17/21