> ## Documentation Index
> Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Smart fields
> Attributes whose value TWICE Commerce works out for you: read from data the record already carries, or fetched from your own API through a connector.
A smart field is an [Attribute](/docs/concepts/admin/attributes) with the format `smart_field`. Nobody types its value: TWICE Commerce reads it from data the record already carries, or fetches it from your own API through a connector.
Reach for one where the value already exists somewhere and copying it by hand goes wrong. A binding setting from a fitting service, a membership level from your CRM, a boot sole length carried over to the skis sold with the boots.
## How it works
### Where the value comes from
Every smart field is one of two kinds, and the editor's first step asks which.
| Source | What it does | What it needs |
| :----------------- | :------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------- |
| **Read from data** | Reads one value that is already on the order, the customer or the units sold together. No outbound call. | One placeholder |
| **Call an API** | Sends your data to a connector and stores the value that comes back. | A connector, a method and endpoint path, a request, and the path to the value in the reply |
### Output type
**Output type** is the format the value is stored, filtered, sorted and grouped as. Pick one of **Text**, **Number**, **Yes / No** or **Date**. A smart field behaves everywhere as a plain attribute of its output type, so a number sorts as a number and a date filters as a date.
The output type cannot change once any record holds a value for the field, and an attribute's format cannot be changed to or from **Smart field** at all. Both take a new attribute instead. Decide the type before you attach the field to records.
### Placeholders
A request is text with **placeholders** in double curly braces. One value has one address:
| Placeholder | Reads |
| :---------------------------------- | :--------------------------------------------------------------- |
| `{{attribute.sole_length}}` | An inventory attribute of the record itself |
| `{{fulfillment.boot_sole_length}}` | A fulfillment field of the record itself |
| `{{order.reference}}` | A built-in field of a data source |
| `{{customer.billingAddress.city}}` | A path into a built-in field that holds an object |
| `{{customer.attribute.level}}` | A customer attribute |
| `{{customer.field.weight}}` | A plain checkout answer, pooled across the customer's line items |
| `{{customerItems.fulfillment.din}}` | The same customer's other units on the order |
| `{{customer}}` | A whole data source, sent as JSON |
Build them with **Insert data** rather than typing them. The picker offers only what the field can reach, and names a placeholder it cannot resolve before you save.
A **Read from data** field takes exactly one placeholder, which is its whole definition. A **Call an API** field may use as many as the request needs.
### Which data a template can read
What a template may address depends on the record the value is computed on, not on where the attribute was defined. Order data is only there when the compute runs from an order.
| Computed on | Can read |
| :----------------------- | :----------------------------------------------------------------------------------------------------------- |
| A SKU | The SKU |
| A stock item | The SKU and the stock item |
| A stock item on an order | The SKU, the stock item, the line item, the listing, the order, the customer, and the customer's other units |
| A customer | The customer |
| A listing | The listing |
A field whose request names order, line item or customer data shows its compute action disabled on the SKU and stock item pages, and says which data is missing there.
### When a value is computed
**Compute automatically** is on by default. With it on, an order fetches the value the first time every input it uses is filled in, and again whenever one of those inputs or the field's own setup changes. Turn it off and the value waits for someone to press **Compute value**.
An order refreshes its values while its status is **Open** or **In progress**. A **Completed** order keeps what it was handed over with, and a draft has nothing to prepare yet.
Each compute stores what its inputs were worth. A later read compares them again, which is how a value that no longer matches the order says so instead of looking current. A stale value names the input that moved, with its old and new value.
A value someone typed, a value inherited from a SKU or stock item, a first fetch that failed, and a value with an input still empty are left alone rather than fetched on their own.
### A value on an order unit
A fulfillment field on a unit can hold values from several places at once. The order shows the first one that has a value:
1. What staff typed on the order
2. The computed result
3. The value read from order data
4. The stock item's value
5. The SKU's value
Typing over an automatic value does not destroy it. The order marks the entry as an override, shows the value underneath on hover, and restores it when the entry is cleared.
### When a compute fails
A failed compute keeps the previous value and records the error on the field. Press the warning to read the whole message, which names the last attempt and the most common causes: a wrong endpoint path, a missing or expired key, or an external service nothing can reach.
Deleting a connector leaves every field using it in place. Each next compute fails with that message and the stored value stays put until the field is given a connector again.
## Usage
### Create a smart field
Connect the API first under **Settings → Integrations & API**, then define the field under **Settings → Attributes & Tags**.
1. Open the resource the field belongs to and add an attribute
2. Choose **Smart field** as the type
3. Pick **Read from data** or **Call an API**
4. For **Call an API**, name the connector, the method and endpoint path, the request, and the response path
5. For **Read from data**, pick the one value the field reads
6. Set the output type, and decide whether it computes automatically
### Where a smart field can live
| Attributes on | Smart field available |
| :------------------- | :-------------------------------------------------------------------- |
| Stock items and SKUs | Yes, computed on the SKU or the stock item |
| Fulfillment fields | Yes, computed on the SKU, the stock item, or a stock item on an order |
| Customers | Yes, computed on the customer |
| Listings | Yes, computed on the listing |
| Orders | No |
A smart field cannot be a global attribute. A global one would put an outbound call on every record in the account, so you attach it to the records that need it.
Smart fields behave as ordinary columns of their output type in the inventory, SKU, catalog and customer tables, including filtering, sorting and grouping. A fulfillment field that is a smart field is filled in on the order like any other, next to the ones staff type.
## Related articles
Formats, input masks, keys, inheritance, and API access.
Connectors, API keys, and webhooks.
Where attributes, fulfillment fields, groups and tags are managed.
The other computed format, worked out from fields on the same record.