The Interactions panel lets you define how flow elements respond to events — such as taps, element appearances, and form submissions. For each event, you assign one or more actions: navigate between screens, show or hide elements, open URLs, set variables, and more. Use conditions to customize the flow based on user data.

Each interaction follows a three-part chain:

1. Element: The screen component that starts the interaction — a button, quiz answer, input field, or anything else.
2. Trigger: The event that activates the logic, such as a tap, an element appearance, or a form submission.
3. Action: The task the flow performs in response. A single trigger can run multiple actions in sequence.

Set up interactions

To set up an interaction:

1. Select an element on the screen or in the Layers panel.
2. On the right, switch to the Interactions panel and click Add trigger.

3. In the Button triggers section, select the trigger type.

4. Click Add action, click the action name, and select an action type from the dropdown in the Edit action window.

5. Configure the action properties based on the action type you selected.
6. If needed, click Add action to add more actions for the same trigger.

Trigger types

Triggers fire in response to user behavior, element state changes, or the screen loading. On screen appear is universal; the others are element-specific.

Trigger	Fires when…	Supported on
On screen appear	The screen loads	All elements
On tap	The user taps the element	Buttons, quiz options, toggles, countdowns, videos
On changed	The user changes the input’s value (typing, picking a date or time)	All input elements
On submit	The user submits a text input by pressing Enter or Done on the keyboard	Text-based inputs
On timer end	A Countdown element reaches zero	Countdown
On playback finished	A Video reaches the end	Video

For elements with no built-in interactions (such as Loader), On screen appear is the only trigger available.

Action types

Navigate to screen

This is the primary action for moving users between screens. It takes the user to a specified destination screen.

For this action, you only need to set up the destination screen. If you want to enable dynamic navigation, see Navigation and branching or the Conditional actions section.

Navigate next

Advances the user to the next screen in the flow’s screen order. Use this for linear flows, where the order of screens in the editor matches the order you want the users to see them.

Navigate back

Returns the user to the previous screen in their navigation history, rather than the previous screen in the sequence.

Open URL

Opens a specific web address. Use this to send users to web pages, articles, or social media profiles outside of your app’s native screens.

For this action, you can configure two settings:

• URL address: Set a URL address. Additionally, you can make it dynamic — for example, to navigate users to different pages based on their quiz answer or using the data they’ve submitted. To do this, click and select a variable you want to use.
• Open in external browser: Define where you want to open external links. By default, they open in an in-app browser to keep users within the app. Select the Open in external browser checkbox if you want to open links in an external browser.

Close flow

Closes the current flow.

Show/hide elements

Shows or hides a specific element on the screen.

This action overrides the initial state set in Visibility in the Design panel. If Visibility is set to Hide, the Show action will make it appear.

Show alert

Displays a native system pop-up window. Users must tap Ok to proceed.

For alerts, you must set up their Title and Message. In both, you can use variables to make the content dynamic. To do this, click and select a variable you want to use.

Set variable

Updates the value of a variable in the flow. Before adding this action, create variables in the Variables panel on the left (see Variables).

Click Add variable and set as many variables and their values as you need.

Purchase

Triggers a purchase flow directly from a button or interaction in your onboarding. Use this to let users subscribe or buy a product without leaving the flow.

You can configure two behaviors for this action:

• In-app store: Initiates a native purchase. Set Product to a specific product, or to products.selectedProduct for the user’s current selection on the screen.
• Web payment: Sends the user to a web paywall instead of triggering a native purchase. Use this when you want to handle the transaction outside the app, such as for web-based subscription offers.

Restore purchases

Triggers the restore purchases flow on the device. Users tap this when they’ve previously bought a subscription on another device or after reinstalling the app, and need to recover access to their entitlements.

There’s nothing to configure for this action — Adapty handles the restore through the native store flow.

The Restore purchases action is also pre-configured on the Restore link in the Links button preset (see Set up purchases).

Custom actions

A custom action fires a named Action ID that your own app code handles. Use it when the built-in action types don’t cover what you need.

Adapty provides the trigger; your app implements the behavior:

1. In the builder, you assign an Action ID to an element’s interaction.
2. When the user triggers the interaction, the flow passes the ID to your app.
3. Your app matches the ID and runs your code.

Set up a custom action

1. In the Edit action window, assign an Action ID — a string your app will recognize (for example, show_discount).
2. In your app code, implement a handler for this Action ID. See Handle paywall actions for implementation details and code examples.

What you can do with custom actions

A custom action does nothing on its own. You set a static Action ID in the builder, and your app code handles what happens when it receives that ID. Every use case below follows the same pattern: assign an ID in the flow, then handle it in your code.

• Trigger an in-app event: Fire an ID such as viewed_special_offer, then log the event to your analytics when your app receives it.
• Request a system permission: Fire an ID such as request_location, then call the OS permission prompt from your app. Adapty doesn’t show the prompt — your app does.
• Start native authentication: Fire an ID such as login_google, then present your own login screen. The flow can’t sign the user in.
• Apply business logic: Fire an ID such as apply_discount, then unlock content or change app state on your side.
• Pass a quiz answer to your app: Assign a different Action ID to each option (for example, goal_weight_loss and goal_muscle), then read the ID in your code. Use the ID to set a custom user attribute you can segment on later. Because the action carries only a fixed ID, this is the only way to report the choice — the flow can’t send the selected value.

What custom actions can’t do

Custom actions are static. The Action ID is fixed when you build the flow — it can’t read variables or user inputs. When the action fires, your app receives only that ID, never the email, phone number, or other input the user entered. Input fields stay inside the flow as variables for branching and personalization. To use those values in your app, collect them through your own UI or API.

Conditional actions

Use conditional actions to split the flow into different paths based on user data.

Some common use cases include:

• You have a quiz on the screen, and you want to navigate users to different screens based on their answers. In this case, add a conditional action to a button.
• You want to offer different products and offers to different user groups. Place them on different screens and set up conditions for a navigation button.
• You want to skip certain steps for users who have already completed a tutorial in a previous app session.

Conditional actions work like an if / else-if / else chain. The app reads the rules from top to bottom and stops at the first match:

1. IF: The flow checks the primary condition.
   • Is it True? The flow executes the THEN actions immediately and stops.
   • Is it False? The flow skips to the next section.
2. ELSE IF: You can add extra checks here (e.g., “If not Premium, is the user on a Trial?”).
3. ELSE (Fallback): If none of the rules above matched, the flow executes the actions in this final section.

For each rule, select a variable to evaluate and an action to run. You can set more than one action per rule.

To learn how to make elements selectable and organize them into groups for use in conditions, see Selectable elements and groups.

Troubleshooting

Any action with missing required fields blocks previewing and publishing. See Save & publish flows for the full list.