> 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/schema-fields-reference/array-element-conditions.md).

# Array Element Conditions

An array element condition is a schema condition whose IF trigger is a field with **Allow multiple answers** enabled, matched against the field's individual entries rather than against the field's value as a whole.

#### The problem it solves

A regular condition compares a field's value to a single literal with `=`. When the trigger field allows multiple answers, its value is a list, and a list is never equal to a single literal — the condition can be created in the editor, but it can never match.

Array element conditions replace `=` with two comparators that make sense for a list, so the trigger field's individual entries — not the list as a whole — decide whether the condition matches.

#### How it works

When the selected IF field has **Allow multiple answers** enabled, the condition editor offers two comparators instead of `=`:

* **contains** — true when any entry in the list equals the match value.
* **= (each)** — true when every entry in the list equals the match value. An empty list never satisfies this.

For a field that does not allow multiple answers, the comparator is always `=`, exactly as it works today.

The comparator is evaluated the same way while the form is being filled in and when the document is submitted, so a field that appears because the condition matched in the form is never rejected on submission for a different reason.

#### Key distinctions

* **Not the same as cross-schema conditions.** A cross-schema condition lets the trigger and target live in different sub-schemas. An array element condition is about the values inside one field's own list, matched against a single literal — the trigger and target can be in the same schema or different ones, independently of which comparator is used.
* **Not the same as repeatable field links.** Repeatable field links pair entries across two fields that both allow multiple answers, so a condition inside one linked entry can trigger on a field inside the matching entry of another. An array element condition works within a single field's own list of values, with no pairing involved.
* **Only for fields with a plain value type.** A field whose entries are themselves sub-schemas is not eligible — array element conditions compare literal values (text, number, boolean), not sub-schema entries.

#### Related

* Task: [Configure an Array Element Condition](/docs/develop/guardian/workspace/schemas/schema-fields-reference/array-element-conditions/configure-array-element-conditions.md)
* Concept: [Cross-Schema Conditions](/docs/develop/guardian/workspace/schemas/schema-fields-reference/cross-schema-conditions.md)
* Concept: [Repeatable Field Links](/docs/develop/guardian/workspace/schemas/schema-fields-reference/repeatable-field-links.md)
* Reference: [Conditional and Visibility Logic](/docs/develop/guardian/workspace/schemas/best-practices-to-implement-schema/conditional-and-visibility-logic.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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://guardian.hedera.com/docs/develop/guardian/workspace/schemas/schema-fields-reference/array-element-conditions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.