> For the complete documentation index, see [llms.txt](https://guardian.hedera.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guardian.hedera.com/docs/develop/guardian/workspace/schemas/repeatable-field-links.md).

# Repeatable Field Links

A repeatable field — a field with **Allow multiple answers** enabled — lets a user add as many entries as they need. Repeatable field links tie those entries to the entries of other repeatable fields, so every entry carries its own, separate set of related fields — including fields that live in other schemas of the same document.

#### The problem it solves

When a policy document tracks several parallel subjects — locations, activities, or measurement periods — each subject needs its own set of related data. Without linked fields, a user would have to manage that relationship manually, and the form has no way to enforce that each subject's data stays grouped together.

Repeatable field links enforce the one-to-one pairing automatically. A user adds one entry to the source field, and every linked field gains a matching entry. The entries stay paired through the entire lifecycle of the form.

#### How it works

When a policy is being filled in:

* Adding an entry to the source field creates a matching entry in every linked field. Linked fields have no manual add or remove buttons — they always follow the source.
* Each entry is labelled with the display name chosen during schema configuration, so entries are easy to identify.
* Fields marked as **Copied values** arrive filled and read-only in the linked entry.
* Removing a source entry prompts for confirmation, then removes its matching entry from every linked field. The remaining entries keep their own values.

Because the entries are paired one-to-one, conditions are also evaluated per entry. The same field can be shown in one entry and hidden in another, depending on the values each entry holds.

**Adding entries**

Add the source entries — here, two project locations:

Each location is its own block with its own fields:

Each linked section then gets a matching entry, labelled by the display name, with copied fields filled and read-only:

**Different fields for each entry**

Each entry runs its conditions independently. The first location chose *Quantification Approach 3* — its monitoring card expands and shows the conditional fields:

The second location chose *Quantification Approach 1* — the same card hides those fields:

#### Key distinctions

* **Cross-schema links are supported.** A dependent field can live in a different schema of the same document, not just in the same schema as the source.
* **Chains are supported.** A dependent field can itself be a source for another field, forming a group of any depth.
* **One source, many dependents.** A single source field can drive several dependent fields at once.
* **Conditions work with nested fields.** In the When clause, fields inside a repeatable group are available as a trigger — and the condition is evaluated independently for each entry.

#### Related

* Task: [Set up repeatable field links](/docs/develop/guardian/workspace/schemas/repeatable-field-links/set-up-repeatable-field-links.md)


---

# 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://guardian.hedera.com/docs/develop/guardian/workspace/schemas/repeatable-field-links.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.