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 for what repeatable groups do support.
Related
Reference: Conditional and Visibility Logic
Concept: Schema Editor
Last updated