> For the complete documentation index, see [llms.txt](https://help.blings.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.blings.io/guides/data-fundamentals.md).

# Data Fundamentals

Data is what lets one MP5 project adapt to different viewers, teams, campaigns, and runtime states. The same data model is used across Studio connectors, Platform settings, simulation profiles, integrations, SDK payloads, and form collection.

Use this guide to understand the main data types before configuring connectors or delivery.

## Main Data Concepts

| Data concept            | What it controls                                                           | Typical examples                                                             |
| ----------------------- | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| **Dynamic Data**        | Viewer-specific or record-specific values.                                 | `first_name`, `account_balance`, `product_image`, `renewal_date`, `cta_url`. |
| **Live Control**        | Shared project-level values that operators can update centrally.           | Brand color, logo, campaign label, active offer, global CTA copy.            |
| **Catalog**             | Reusable grouped records referenced by the project.                        | Products, plans, offers, locations, benefit cards, recommendations.          |
| **Integration payload** | Runtime data delivered by CRM, SDK, URL, spreadsheet, API, or custom code. | CRM tokens, SDK `data` object, CSV row values, URL parameters.               |
| **Form Data**           | Values submitted by viewers from inside the MP5 experience.                | Lead fields, answers, preferences, registrations, feedback.                  |
| **Internal fields**     | Values used by project logic but not meant for normal business editing.    | Routing flags, helper values, technical IDs.                                 |

## How Data Moves Through a Project

{% stepper %}
{% step %}

### Define the Schema

Create fields, groups, types, defaults, internal fields, catalog item fields, and live controls in the project data model.
{% endstep %}

{% step %}

### Bind Fields in Studio

Use connectors to bind data fields or live controls to text, media, colors, visibility, buttons, branches, inputs, and other behavior.
{% endstep %}

{% step %}

### Pass Runtime Values

The selected delivery method passes viewer values from a CRM, spreadsheet, SDK, URL, API, or another integration source.
{% endstep %}

{% step %}

### Validate With Simulation

Platform simulation profiles and Studio previews confirm that real values, missing values, long values, and alternate states render correctly.
{% endstep %}

{% step %}

### Collect New Values When Needed

If the viewer enters data in the MP5 experience, Input Field and Submit Form connectors can send those values to Form Data or custom handling.
{% endstep %}
{% endstepper %}

## Naming Rules

Use field names that can survive handoffs between creative, operations, and engineering:

* Prefer lowercase names with underscores, such as `first_name` or `offer_price`.
* Give one field one meaning. Do not reuse a generic field like `status` for unrelated logic.
* Match field names exactly between Studio, Platform, CRM, SDK, spreadsheets, and custom code.
* Set defaults for fields that affect visible text, media, colors, links, dates, and routing.
* Use Live Control for shared values instead of duplicating the same value across every viewer record.
* Use Catalog for repeated grouped records instead of creating many one-off fields.

## Data QA Checklist

Before launch, confirm:

* Required fields exist in the schema and in the runtime source.
* Types match how each connector uses the value.
* Defaults keep the experience readable when runtime data is missing.
* Images, videos, links, dates, colors, and numbers use valid formats.
* Conditions and branches have fallback paths.
* Simulation profiles cover normal, empty, long, invalid, and edge-case values.
* Form Data collection is approved and tested if the project collects viewer input.

## Deep Dives

{% content-ref url="/pages/vF3GOo8viXK19zuT75hD" %}
[Data in Studio](/apps/blings-studio/data.md)
{% endcontent-ref %}

{% content-ref url="/pages/tcTMJOKSy05H4hRxVQ8F" %}
[Data, Catalog, and Forms](/apps/blings-platform/data-catalog-and-forms.md)
{% endcontent-ref %}

{% content-ref url="/pages/rTx9aOZIbm1v2elhBsNO" %}
[How to connect my data to the video](/role-guides/developer/getting-started/how-to-connect-my-data-to-the-sdk.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.blings.io/guides/data-fundamentals.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.