Interactions
Connect triggers, decisions, actions, and outcomes in Flow
Use Flow to define what happens when a customer taps, swipes, reaches a screen, completes a purchase, or satisfies a condition. The canvas shows the Journey as connected triggers and actions instead of hiding behavior inside individual screens.
The model
An interaction starts with a trigger and follows one or more actions.
- A trigger is the input: Start, Tap, Long Press, Touch Down, Touch Up, Pan, Hover, Event / Screen, a variable change, or a manual invocation.
- An action is the work: navigate, wait, branch, send an event, update the user, purchase, collect a response, request permission, ask the app to act, dismiss, or exit.
Actions execute in order. Navigation and terminal actions can end the current path, so place analytics, response, and milestone work before the terminal step when it must happen first.
Connect screens
- Switch to Flow.
- Select the source screen or interactive element.
- Add or select a trigger.
- Add a Navigate action and connect it to the destination screen.
Use Back when the Journey should return to the prior navigation state. Use Dismiss to close the Experience and Exit when the Journey should end with an explicit reason.
Common actions
| Intent | Action |
|---|---|
| Move between screens | Navigate or Back |
| Pause or await state | Delay or Wait Until |
| Choose a path | Condition or Experiment |
| Record product behavior | Send Event or Set User Property |
| Record Journey progress | Milestone or Goal |
| Sell or recover access | Start Purchase or Restore Purchases |
| Collect structured input | Set Response Field or Submit Response |
| Ask for native access | Request Notifications, Permission, or Tracking |
| Ask the host app to perform custom work | Run App Action |
| Run a server integration | Run Connector Action |
The available actions depend on the selected node and runtime. The editor validates unsupported platform actions before publish.
Conditions and variables
Conditions can use supported Journey context, user state, Products and Features, responses, and backed screen variables. Use the Data surface to inspect the values that exist; do not create a binding to a path that has no declared source.
For complex behavior, ask Nuxie to build the path and then inspect it in Flow:
If the customer selects annual, start the annual purchase. On success, record the purchase milestone and dismiss. On cancellation, stay on this screen. On failure, reveal the recovery message.
Validate behavior
Use Preview to exercise every meaningful branch before publishing. Check at least:
- the happy path;
- dismissal and back behavior;
- purchase cancellation, pending, and failure paths;
- empty or unavailable dynamic data;
- permission denial;
- any response submission or App Action.
Publish review catches structural errors, but it cannot decide whether a valid path matches your product intent.