# Condition settings Source: https://govform.com/resources/documentation/article/26-condition-settings Topic: Condition Settings 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. | Need | Suitable approach | | --- | --- | | A choice includes a selected option | use the choice operator with the stable selection item ID | | A text field matches a known code | use an exact string comparison | | A number crosses a threshold | use a numeric comparison | | A date is before or after a point | use a date comparison and ISO-format values | | A value is present | use the defined/not-defined operator without an unnecessary value | | A lookup or action succeeded | use the relevant result or status operator | 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 | Attached to | Effect | | --- | --- | | Page flow | includes or skips a page in the journey | | Component visibility | shows or hides relevant content | | Validation | makes a requirement apply only on the relevant route | | Action execution | decides whether an action runs | 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. ## Condition properties and operator boundaries A rules condition uses `elements` joined by `elementsOperator` (and by default, or). A template condition uses `predicateTemplate` returning true/false. Field `conditionIds` apply conditional validation; they do not hide a field. Use page conditions, choice reveals or the dedicated visibility controls for visibility. Ordinary rules offer text equality, field comparisons, numeric/date comparisons, choice membership and defined/lookup/action-status tests. String contains/starts-with/ends-with/regex/fuzzy lookup operators belong to Feed/SharePoint lookup filters, not ordinary condition elements. Use a concise template condition when a required string test is outside the ordinary rule operators. ## Related guidance - [Use conditions and branching]() - [Page conditions and advanced behaviour]() - [Selection item settings]() - [Shared action settings]()