> For the complete documentation index, see [llms.txt](https://docs.guardianservice.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.guardianservice.app/technical-information/users/standard-registry-users-schemas-and-policies/schemas/cross-schema-conditions.md).

# Cross-Schema Conditions

Let a field in one sub-schema control a field in a different sub-schema.

A cross-schema condition lets a field in one referenced sub-schema control a field in a **different** referenced sub-schema on the same parent. The condition is defined on the parent schema that owns both sub-schema references.

## The problem it solves

Sub-schemas are designed to stay independent and reusable across policies. Sometimes a field in one sub-schema must determine a field in another.

Without cross-schema conditions, the usual workaround is to merge schemas or duplicate fields on the parent. Both approaches reduce reuse and make maintenance harder.

Cross-schema conditions keep that relationship on the parent schema, so each sub-schema stays self-contained.

## How it works

A cross-schema condition uses the same `if/then/else` structure as a regular condition, with two differences.

**The trigger is a nested field.** The **When** clause points to a leaf field inside one referenced sub-schema. The field picker groups these under each sub-schema name, with the parent schema's own fields at the top.

A condition block can test one rule or several. The block header switches between **IF** (a single rule), **IF ALL** (every rule must match), and **IF ANY** (at least one rule must match).

**THEN and ELSE branches can target fields in other sub-schemas.** Each branch has a **Ref field** picker listing fields inside referenced sub-schemas. An option that is a whole sub-schema rather than a single field carries a **Sub-schema** badge, and selecting it adds one target for the entire block instead of listing every field it contains.

Added targets appear in the branch as a path, for example `Project Details › Location › region`, with an **open** control that jumps to the target schema.

When a branch is active, the target field appears in its sub-schema. When it is inactive, the field is hidden and must not appear in the submitted document.

Guardian compiles this into a standard JSON Schema `if/then/else` block on the parent schema, using nested `required` rules and `false` property constraints.

## Key distinctions

**The condition belongs to the lowest common ancestor.** That is the schema that references both the sub-schema containing the trigger field and the sub-schema containing the target field. That placement keeps the sub-schemas independent, since neither needs to know about the other.

**Repeatable fields cannot take part.** Fields inside a repeatable (array) sub-schema are not offered in the trigger picker or the branch target pickers, and the repeatable container itself is not offered as a target. A condition compiles to `properties` and `required` walked along a path, with no `items` step, so against an array it either does nothing or is enforced on every entry unconditionally. Rather than let an author configure a rule that cannot be enforced, MGS leaves those fields out of the pickers. See [Repeatable Field Links](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/repeatable-field-links.md) for what repeatable groups do support.

## Related

* Task: [Configure Nested and Cross-Schema Conditions](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/cross-schema-conditions/configure-nested-and-cross-schema-conditions.md)
* Reference: [Conditional and Visibility Logic](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/best-practices-to-implement-schema/conditional-and-visibility-logic.md)
* Concept: [Schema Editor](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/schema-editor.md)