You can implement a hidden step when the preceding step prompts the user to act on your application, and you do not want any Userflow interface to appear while you wait for the user to complete their task.
Caution
Hidden steps must include at least one trigger that reliably activates within the current user session and leads to either a visible step, a new flow, or flow termination. Hidden steps can pose a risk if their triggers fail to activate or take too long to match, users become stuck indefinitely. While users won’t see any Userflow UI (which may be acceptable), the active flow session blocks other content including flows, checklists, and launchers, from appearing.
Requirement: Users must exit hidden steps quickly to prevent content blocking and ensure an optimal user experience.
One thing to keep in mind is that the triggers for your hidden steps must also account for the possibility that the user could do the wrong thing. This is where you want to make sure the user does not get stuck.
Example: To implement a project creation workflow, we could direct users to select New project, which triggers the modal in the app to appear. Then, we want Userflow to remain hidden during this interaction until the user has successfully created a project and continues the flow. It could look something like this:
What could go wrong with this approach? What if the user closes the Create project modal in the app instead of completing it? Then they’d be stuck on Step 2 indefinitely, because they never clicked the Create project button.
Here’s a video walkthrough explaining a better way to accomplish this goal:
Try to avoid hidden steps
Our general recommendation is to only use hidden steps when absolutely necessary.
If you’re waiting for the user to perform some action, it’s usually easier to just use a speech bubble or a tooltip telling them what to do. See the video above.
If you’re using a hidden step like a “logic router”, which conditionally goes to another step or navigates to a different URL depending on some condition, then it’s often easier to just move those triggers to the previous/next step and delete the hidden step. Here’s an example:
Let’s say we have a flow where we want to ensure the user is on the correct URL before starting. We could do this with a hidden step:
The logic is that if the user is on the correct page in Step 1, then they proceed to Step 2 and let the actual flow begin (the first trigger), if they’re not on the correct page, then it should send them to the correct page first via a “Navigate to page” action (the second trigger).
We could simplify this by moving the second trigger to Step 2 and deleting all of Step 1:
Using the Debugging tool to troubleshoot
If you use the Debugger tool to troubleshoot when a user gets stuck in a hidden step of an active flow, the status Another flow is currently active will display in the Debugger.
.png)