---
title: "Data and bindings"
description: "Use answers and other values to personalize screens and choose what happens next."
search:
  tags: ["Features"]
  keywords: ["personalization", "dynamic text", "response field"]
---

Bindings connect a component to data in the Experience. An input can save an answer, a heading can display it, and a condition can use it to choose the next screen. For example, onboarding can ask what someone is training for and use their answer in a personalized plan summary.

<span id="define-the-data" />

## Response fields and variables

Response fields hold answers you want to collect from users. Group them in a response collection, such as a collection containing `goal`, `experience_level`, and `weekly_sessions` for onboarding.

Choose a field type based on the answer:

- **Text** for a written answer, such as a goal in the user's own words.
- **Number** for a numeric value, with optional minimum and maximum values.
- **True / False** for a yes-or-no answer.
- **Single select** for one choice from a list, such as an experience level.
- **Multi select** for several choices, such as preferred training days.
- **Date** for a date, such as an upcoming race.

Each field needs a unique key within the collection. Keys start with a letter and can contain letters, numbers, and underscores. Select options must be nonempty and unique, and a number field's maximum must be at least its minimum.

Use variables for other values the Experience needs, such as a selected tab or animation state. These values don't need to become collected answers.

### Attach a response collection

1. **Add the Response capability**

    Select a screen on the Canvas and choose **Add capability → Response**.

2. **Choose a collection**

    Choose an existing collection or create a new one.

3. **Configure its fields**

    Open **Edit fields** to configure the collection.

The screen's **Response** section shows its collection and fields. Choose the collection row to replace it with a different collection.

You can also manage fields from **Responses** in the Experience header. Select the collection, open **Fields**, and choose **Add field**. Set the key and type, then choose **Save changes**. Each save creates a new version of the field definitions, so collected answers remain associated with the fields used at the time.

<span id="bind-components" />

## Component bindings

An input writes a value; the content that uses the answer reads the same field. For example, the **Run a 5K** option can save `run_5k` in `goal`, while a summary reads `goal` to show the selected plan.

After attaching the response collection, ask Nuxie to connect the controls to it:

**Connect the goal choices to the response field `goal`. Save `run_5k` when someone selects Run a 5K. On the summary screen, use their chosen goal to show the matching plan. If they skip the question, show the general plan.**

> Connect the goal choices to the response field `goal`. Save `run_5k` when someone selects Run a 5K. On the summary screen, use their chosen goal to show the matching plan. If they skip the question, show the general plan.

Open **Preview**, choose **Run a 5K**, and continue to the summary. The answer should affect the summary immediately, before the response is submitted. Changing the answer and returning to the summary should show the new choice.

Conditions use those same values. If a branch checks whether `experience_level` is `beginner`, the input needs to save `beginner`. For optional answers, give the content or condition a fallback so the Experience can continue when the field is empty.

### Reusable component inputs

A reusable component's inputs can use the component default, a value entered for one instance, or compatible screen data. To connect an input to data, open its source menu and choose a field under **Use screen data**.

The input then shows which field it reads. **Unbind** returns it to the default source. **Reset to default** removes a value entered on the instance. If the menu shows **No matching fields**, the screen has no available field of a compatible type.

## Variable collections

Variable collections keep related values together. For example, a collection can hold a set of colors, with separate modes for light and dark treatments. Each mode supplies values for the same variables.

Open **Code** in the Experience header to create or select a collection. You can add named variables, edit their values, change their types, rename them, or delete them. Use **Add mode** in the collection menu to add another set of values. Activating a mode applies it to the selected screen.

**Values and aliases**

A variable can contain a value of its own or an alias to another variable. An alias follows the other variable's value. Convert it to a literal when you want to edit it independently.

## Animation data

In **Animate**, screen data can be **On / off**, **Number**, **Text**, **Choice**, or **Trigger**. Starting values set the animation's initial state. While a state machine plays, change a value to see how its conditions respond, or choose **Fire** on a Trigger to send a one-time signal.

Changes made while it plays affect your live preview. These values can control animation without being added to a response collection.

<span id="submit-responses" />

## Response submission

An input updates the current answers as the user interacts with it. **Submit response** records those answers as submitted. Put this step after the final answer and before the action that finishes the questions. Moving to another screen alone doesn't submit them.

On the Canvas, drag a wire from the final Continue output into empty space. Choose **Submit response** from **Add to the Journey**, then connect the following step. You can also ask Nuxie to add submission to an existing path:

**When someone continues from the summary, submit their onboarding answers, then run the `start_workout` App Action with their selected `goal` in its payload.**

> When someone continues from the summary, submit their onboarding answers, then run the `start_workout` App Action with their selected `goal` in its payload.

The response records what the user answered; the App Action tells your app what to do with that answer. In this example, your handler receives `start_workout` and the chosen goal, then opens the appropriate workout. [Run App Actions](/docs/ios-sdk/presenting-experiences#run-app-actions) shows the iOS handler; other platforms expose App Actions in their [SDK references](/docs/reference).

[Collected responses](/docs/guides/collected-responses) distinguish **Draft**, **Submitted**, and **Abandoned** records and retain the field-definition version used to collect them. The submitted onboarding record belongs to that user's Journey and contains the answers collected by the attached response collection.