> For the complete documentation index, see [llms.txt](https://docs.amltd.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amltd.com/dc-works/core-concepts/records-and-data-binding.md).

# Records and Data Binding

**Applet records** hold the working data used by fields, actions, and conditions while an Applet is running.

**Data binding** connects an Applet field to a value in a record. This allows information to move between the Applet interface and its working data.

```mermaid
flowchart LR
    F["Applet Field"] <--> R["Applet Record"]
    R <--> A["Actions and Conditions"]
    R <--> T["Table Data"]
```

### Understanding Applet records

An Applet record can contain:

* A single entry with one set of values.
* A list containing multiple entries.
* Values entered by the user.
* Values set or changed by actions.
* Information retrieved from a table.
* Information that may later be added or applied to a table.

A record may remain entirely local to the Applet. Its values are not automatically stored in a table.

### Local records

A **local record** holds temporary or working information within the Applet.

For example, a local record might hold:

* A scanned barcode.
* A user’s selection.
* A temporary status.
* Information collected across several pages.
* A calculated value.
* A value used by a condition.

Actions can set or modify these values, and conditions can evaluate them as part of the workflow.

{% hint style="info" %}
Information in a local record is not automatically saved to a table. An appropriate action must add, append, or update the table data.
{% endhint %}

### Single records and record lists

A record can contain either one entry or a list of multiple entries.

A **single record** might represent one selected asset:

| Asset Number | Description     | Location  |
| ------------ | --------------- | --------- |
| LT-1042      | Shipping Laptop | Receiving |

A **record list** might contain several assets retrieved from a table:

| Asset Number | Description     | Location  |
| ------------ | --------------- | --------- |
| LT-1042      | Shipping Laptop | Receiving |
| SC-2081      | Barcode Scanner | Warehouse |
| TB-3015      | Rugged Tablet   | Shipping  |

Record lists are commonly used to:

* Display multiple entries.
* Hold search or filtered results.
* Allow the user to select an entry.
* Pass a selected entry to another page.
* Process multiple entries within a workflow.

### What data binding does

Data binding connects an Applet field to a particular value in an Applet record.

For example:

```mermaid
flowchart LR
    I["Asset Number Field"] <--> V["Asset Number Value"]
    V --> R["Asset Check-In Record"]
```

When the user enters or scans an asset number, the field can place that value into the bound record. If an action later changes the record value, the field can display the updated information.

Binding allows the interface and the record to work together without making the field itself responsible for storing persistent table data.

### Working with table data

Applet records provide the connection between the interface and information stored in tables.

A typical workflow may:

1. Collect information through Applet fields.
2. Place the information into a local record.
3. Validate the values using conditions.
4. Add or append the record as a new table entry.

Another workflow may:

1. Search or filter a table.
2. Retrieve one or more entries into an Applet record.
3. Display those entries in Applet fields.
4. Allow the user to select or modify an entry.
5. Update the existing table entry through an action.

```mermaid
flowchart TD
    T["Table"] --> R["Applet Record or Record List"]
    R --> F["Bound Applet Fields"]
    F --> R
    R --> O["Add, Append, or Update Action"]
    O --> T
```

### Binding does not save data

Binding a field to a record value does not automatically add or update an entry in a table.

The intended operation must be performed by an action:

| Operation     | Purpose                                              |
| ------------- | ---------------------------------------------------- |
| Set           | Assigns or changes a value in an Applet record       |
| Retrieve      | Loads information from a table into an Applet record |
| Add or Append | Creates a new entry in a table                       |
| Update        | Changes an existing table entry                      |

{% hint style="warning" %}
A value may appear correctly in an Applet field while existing only in a local record. Verify that the workflow includes the required Add, Append, or Update action when the information must be stored permanently.
{% endhint %}

### Plan records carefully

When planning an Applet, consider:

* Which information is temporary?
* Which information must be stored permanently?
* Does the record need one entry or a list of entries?
* Which fields should be bound to each record?
* When should information be retrieved from a table?
* When should a new entry be added?
* When should an existing entry be updated?
* Which values should be validated before they are saved?

Clear record names also make bindings, actions, and conditions easier to understand. Names such as **New Asset Check-In**, **Selected Asset**, or **Asset Search Results** communicate more than generic names such as **Record 1**.

### The Getting Started example

In the **Asset Check-In** Applet, fields are bound to values in Applet records. Those records provide the working information used to create, display, or update entries in the Asset Check-In table.

The Applet record acts as the working layer between the user interface and the persistent table data.

### Next

Continue to **Actions, Conditions, and Workflows** to learn how DC Works uses record values to perform operations and control what happens next.


---

# 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, and the optional `goal` query parameter:

```
GET https://docs.amltd.com/dc-works/core-concepts/records-and-data-binding.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.