Skip to main content
Actions and transitions define the behavior of a flow. They answer a simple question: when a user interacts with this screen, what should happen next?

​
What actions and transitions are made for

Use them to:
  • Move users forward or backward in a journey
  • Send users to a specific screen
  • Finish a flow cleanly
  • Open a website or deep link
  • Ask for a device permission at the right moment

​
How transitions work

Every interactive element can trigger an action. In most flows, that action is connected to a button. Once the action is set, Flowboard uses it to decide the next step in the journey.

​
Common action types

Sends the user to a specific screen. Use this for branching journeys, skip logic, or segmented paths.
Ends the flow. Use this on the last step or when a user has completed the key outcome.
Triggers a permission request, such as notifications, camera, location, or photo access.
Native ask for rating the app and go next.
Opens external website.

​
How to build a reliable flow path

1

Start with the screen order

Put your screens in the order that matches the default path you expect most users to follow.
2

Assign actions to interactive elements

Check every primary button and make sure it has the correct behavior.
3

Use jump rules only when needed

Branching is powerful, but too many alternate paths make a flow harder to maintain and harder to analyze.
4

Review the flow preview map

Use the flow preview to confirm that the routes match your intent before you publish.

​
When to use linear flows vs branching flows

Linear flow

Best when every user should follow the same sequence. This is simpler to maintain and easier to measure.

Branching flow

Best when the next step depends on a user choice, segment, or special permission moment.

​
Best practices

  • Give each screen one clear primary action.
  • Keep branching logic easy to explain to someone outside your team.
  • Place permission requests only after you have explained the value to the user.
  • Test every path in preview, not just the happy path.
  • Avoid dead ends where a screen has no clear way forward.
If your team uses custom actions connected to app-specific behavior, document the intended result internally so non-technical teammates still understand what that step does.