Conditions let one service adapt to the information a person has already provided. Use them to show a relevant follow-up, skip an inapplicable page, require an answer only when it matters, or control when an action can run. A well-designed condition makes the journey shorter without making its logic mysterious.

Choose the lightest-weight solution

Start by deciding what is actually changing.

Avoid using a condition merely to make a long page look shorter. If the follow-up is important, complex, or changes the next steps, a separate page is usually clearer.

Create a rule condition

Open Conditions from the service navigation and select Add condition. Give it a name that describes the business decision, such as Applicant is under 18, rather than a technical description of the first field it checks. The condition ID must be unique and uses letters, numbers and underscores; choose a stable ID because it can be selected elsewhere in the service.

Build the rule by selecting:

1. A source value, such as a component answer, action result, an existing condition or context value.
2. An operator that fits the value type.
3. A value to compare with it.
4. Whether all rules must match (AND) or any rule may match (OR).

For a choice component, compare against the selection item ID rather than its visible label. This keeps the rule reliable if the wording changes or the service is translated. The operator contains selection item is intended for a checkbox or other multi-select answer.

Understand the route before configuring it

flowchart TD
    A["Person gives an answer"] --> B["Condition is evaluated"]
    B -->|"True"| C["Relevant field, page or action is available"]
    B -->|"False"| D["It is hidden, skipped or does not run"]
    C --> E["Person continues and can review their route"]
    D --> E

For page branching, open the relevant page and choose Flow conditions. Add the conditions that must be met for the page to appear. When a person reaches that point in the journey, the Builder evaluates the selected conditions. If they are not met, the page is skipped.

Use this deliberately:

• All selected conditions is suitable when every criterion is necessary, for example a particular application type and a stated circumstance.
• Any selected condition is suitable where several independent answers lead to the same page.
• NOT reverses a condition. Name the resulting logic plainly so that it remains understandable during future changes.

Do not rely on a hidden page as the only explanation of an important decision. The visible route should still tell people why information is, or is not, being requested.

Use template conditions sparingly

Select Template Liquid when a visual rule cannot express the required logic. Template conditions are powerful but harder for a future editor to understand. Keep the template short, format it consistently, and add a plain-language explanation in the condition name or service notes.

For example, an expression may test a stored answer:

{{ fields.applicationType == "renewal" }}

The field identifier and comparison value must match the configured data exactly. Treat identifiers as part of the service design: changing one later can affect conditions, actions, templates and review content.

Tip: If a template condition needs several nested tests, first consider whether separate named rule conditions would be easier to test and maintain.

Conditions outside the page route

Conditions can also be selected in component and action settings. Common uses include:

• Showing a follow-up field only when an earlier answer makes it relevant.
• Applying validation only when a question is applicable.
• Preventing an action from sending, assigning, exporting or changing status unless the service is in the right state.

Be explicit about the outcome when a condition is false. For example, a conditional field may be hidden, but its previous answer may still exist in the draft. Decide whether that value should be retained, cleared or excluded from downstream use, then test the behaviour rather than assuming it.

Test every branch in User view

A condition is not finished when its rule looks correct. Test it from the person’s point of view.

1. Start a new journey and follow the route where the condition is true.
2. Start again and follow the false route.
3. Go back, change the earlier answer, and continue to confirm the route recalculates correctly.
4. Visit Check your answers where the service uses one, and use its change links.
5. Check validation on any conditionally required field.
6. Confirm that an action only runs on the intended route.
7. Repeat the checks in QA before deployment.

Also test direct links and any permitted out-of-order navigation. Those paths can expose assumptions that are hidden when everyone follows the ideal linear route.

Keep branching maintainable

Keep each condition focused on one decision and reuse named conditions where the same rule applies in more than one place. When changing a choice list, page order, component ID or template, search the service for the conditions that depend on it. Review the journey flow afterwards: a valid condition can still create an awkward route if it sends a person past needed guidance or into an unexplained end page.

Related guides

• Design pages and navigation
• Add and configure components
• Write Liquid templates
• Test, deploy and maintain a service