Skip to main content
An interaction wires a component event (a tap, or the screen appearing) to a list of actions. When the event fires, the actions run top to bottom. Actions are how a flow does things: change a variable, move to the next screen, fire an analytics event, play a haptic, close the flow.

​
Where interactions live

Select a component, open the Logic tab in the properties panel, and find the Interactions section. For a custom component the same section is labelled Tap Behavior. The section has:
  • A When picker that chooses which event the action list responds to.
  • A Disabled toggle (which can itself be a dynamic value).
  • The action list, with an Add button.

​
Events

For a built-in component, the When picker offers two events:
Picker labelEventWhen it fires
On TaponPressThe user taps the component
On AppearonAppearThe screen shows the component
On Appear runs once when the screen appears. Pair it with delayed actions to step a value over time (for example, walk a bound number from 0 up to a target). The schema also defines onChange, onFocus, and onBlur, but you do not author those here. They are handled implicitly. A text input, for example, writes its value into a bound variable on its own. For a custom component, the picker is When Event and lists the events that component declares in its definition (its customEventKey values), not the built-in events.

​
The action list

Click Add to append an action. Each action row has:
  • A type dropdown (what the action does).
  • Config fields for that type.
  • A Delay field in milliseconds.
Actions run in the order they appear in the list. Delay is an absolute offset from the moment the event fired, not a wait after the previous action. A list of [Set Variable @ 0ms, Set Variable @ 1000ms] changes the variable now and again one second later, independent of each other. Leave Delay empty or 0 to run immediately.

​
Action types

The type dropdown offers these actions:
Type (label)What it doesKey fields
Navigate to ScreenJump to a specific screenthe target screen
Go to Next ScreenAdvance along the flow ordernone
Go BackReturn to the previous screennone
Close FlowDismiss the whole flownone
Set VariableApply an operation to a variablevariable, operation, value
Open URLOpen a linkthe URL
Haptic FeedbackPlay device hapticintensity (Light / Medium / Heavy)
Trigger EventSend an analytics eventevent name
Trigger AnimationRun a reactive animation step on a componenttarget component, step
Trigger Particle EffectPlay a particle bursteffect and options
A few notes on individual actions:
  • Navigate to Screen picks one fixed screen from a dropdown. The target is not itself a dynamic value. For state-driven paths, see Navigation and branching.
  • Go to Next Screen follows the flow’s screen order, so it stays correct as you add and reorder screens.
  • Trigger Event is FlowPilot’s trackEvent action. The field is labelled Event Name and becomes the event’s key in your analytics. See Analytics (iOS) for how events reach your tools.
  • Trigger Animation targets a component and one of its reactive animation steps. See Animations.
  • Trigger Particle Effect plays an effect overlay. See Particles.

​
Set Variable operations

Set Variable is the main way to change state. Only Flow State variables appear in its picker (App Parameters are read-only). The operations offered depend on the variable’s type:
Variable typeOperations
BooleanSet ON, Set OFF, Toggle
NumberSet to value, Increment by, Decrement by, Multiply by, Divide by, Reset to initial
StringSet to value, Append, Prepend, Clear
ListAdd item, Remove item, Toggle item, Clear list, Set list
A Quick Actions strip offers one-tap presets for the most common operations (Toggle on/off, Next step, Toggle selection, Clear selections, and so on) based on the variable’s type.

​
Two more actions in the schema

Two action kinds exist in the flow schema but are not in the type dropdown:
  • assign evaluates an expression into a variable. The editor uses it under the hood (for example, a custom component’s output payload is compiled into assign-style writes), so you do not add it by hand.
  • custom carries an actionKey and params for native handling. You can reference custom behavior through custom components, but native handler registration is not a public iOS SDK API yet. Do not rely on a custom action doing anything on device. See Custom components (iOS) and the actions reference.

​
Example

A Continue button. On a “Continue” button, set When to On Tap and add, in order:
  1. Set Variable -> step -> Increment by -> 1
  2. Trigger Event -> Event Name continue_tapped
  3. Go to Next Screen
The variable updates, the event is recorded, then the flow advances. Order matters: if Go to Next Screen came first, the screen would change before the variable was set. A staggered reveal. On a screen’s component, set When to On Appear and add two Set Variable actions on the same bound value with different Delays (for example 0ms and 400ms). Because each delay is measured from when the screen appeared, the value steps from one state to the next on its own.

​
Preview is not the runtime

The editor’s preview is a close approximation, not the device runtime.
  • In edit mode (not previewing), only visual and sensory actions fire: Trigger Animation, Trigger Particle Effect, and Haptic Feedback. Navigation, Set Variable, Close Flow, Open URL, Trigger Event, and custom actions do not run, so a stray click on a wired button will not switch screens or change state while you author.
  • In preview mode, state and navigation actions run against preview-only state. Navigation, variable changes, and the like update the preview and show a toast; they never touch real flow data. Open URL shows a confirmation rather than leaving the editor.
Use a real build to confirm end-to-end behavior.

​
Common mistakes

  • Wrong action order. Putting Go to Next Screen before a Set Variable means the variable never gets set on the screen the user just left. List state changes before navigation.
  • Navigating to a deleted screen. A Navigate to Screen action that points at a screen you later delete has no valid target. Re-point it.
  • Expecting custom to work on device. Custom actions have no public native handler on iOS yet. Treat them as not-yet-functional on device.
  • Authoring onChange by hand. Input changes are wired implicitly through variable binding, not through the action list.