Conditions are reusable yes-or-no decisions. They can control whether a page or component is shown, whether validation applies, or whether an action runs. The condition itself does not decide its effect; that comes from where you attach it.

Design conditions as small, named business rules. A condition called is_eligible_for_fast_track is far easier to reuse and test than an unnamed collection of comparisons hidden in several places.

Choose rules or a Liquid template

Use a Rules condition for a straightforward comparison between fields, action results, context values or other conditions. Use a Template condition only when the logic cannot be represented clearly with the structured rules.

flowchart TD
  A[Business rule] --> B{Can simple comparisons express it?}
  B -- Yes --> C[Rules condition]
  B -- No --> D[Liquid template condition]
  C --> E[Attach to page, component, validation or action]
  D --> E

Structured rules are usually easier for another builder to inspect. A template condition is appropriate for genuinely calculated logic, but should remain concise and return a clear true or false outcome.

Create a reusable condition

1. Open the service Conditions area and add a condition.
2. Give it a stable Condition ID, a clear Name and a useful description for maintainers.
3. Select Rules or Template.
4. Add the comparisons or Liquid predicate.
5. Choose all rules or any rule when there is more than one rule.
6. Attach the condition where it has the intended effect.
7. Test both true and false outcomes in User view and QA.

Do not change a condition ID casually once pages, components or actions use it. Update every reference and test every affected journey route when an ID or business meaning changes.

Write rules precisely

Each rule has a left-hand value, an operator and, for most operators, a right-hand value. Refer to the appropriate field, action, condition or context value. Use the right operator for the data type.

For choice fields, compare against the selection item ID, not the visible label. IDs remain stable when wording changes. For dates, use the expected date format and test boundary cases, including today and empty values.

Combine rules with intention

Use all rules (AND) when every requirement must be true, such as an adult applicant who has selected a particular service. Use any rule (OR) when any one route qualifies, such as one of two approved organisations.

Avoid mixing several unrelated decisions into one large condition. Create smaller conditions and, where useful, reference them from another condition. This keeps changes and test cases focused.

Use template conditions sparingly

A template condition has access to the service’s current fields, actions and form information. It must resolve to true or false. Name the condition after the business decision, not the implementation detail, and document why rules were insufficient.

Test missing values, optional fields, unexpected text and every branch of the template. Do not use a template condition to hide validation errors or to execute an external operation; it should only evaluate the decision.

Simulate without changing live behaviour

Condition flow simulation value can force a condition true or false in Builder flow simulation. It helps explore routes while designing, but does not change the live condition. Leave it unset unless you are deliberately simulating a path, and do not use simulation results as a substitute for User view and QA testing.

Attach conditions in the right place

Review the attachment as well as the condition. A condition can be correct but have the wrong outcome when attached in the wrong location.

Test checklist

• The condition has a stable ID, clear name and maintainable description.
• Rules are used where they express the decision clearly.
• Operators match the type of value being compared.
• Choice comparisons use stable item IDs, not labels.
• AND/OR logic matches the written business rule.
• Template conditions return clear true/false outcomes for all expected inputs.
• The condition is attached where it has the intended effect.
• Both true and false routes work with back navigation and saved drafts.

Related guidance

• Use conditions and branching
• Page conditions and advanced behaviour
• Selection item settings
• Shared action settings