A calculated component displays information derived from the journey and can also hold the calculated value for later use. Use it when the service needs to show a result, summary, price, eligibility message or other derived information without asking the person to type it.

For a static explanation, use an information component. For a value the person needs to enter or edit directly, use an input component with appropriate pre-population instead.

Decide what is calculated and what is displayed

The calculated value and the displayed content serve different purposes:

• Calculated value: the value that conditions, actions, templates or other components can use.
• Display content: the explanation, result or contextual message the person sees.

flowchart LR
  A[Earlier answers] --> B[Calculation or pre-populated template]
  B --> C[Stored calculated value]
  B --> D[Displayed result or explanation]
  C --> E[Conditions, actions and templates]
  D --> F[Person reviews the journey]

Keep the calculation simple and name the component ID after the value it represents, such as estimated_total or eligibility_result. Avoid making a calculated value do two unrelated jobs.

Build and test the calculation

Use the pre-populated value setting to create the calculated value from Liquid. A simple example combines two values already gathered in the journey:

{{ quantity | times: unit_price }}

Test the calculation using realistic answers, including zero, empty optional values, unusually long values and a person changing an earlier answer. If the result depends on values on the same page, the component can be recalculated as the person types. Use live recalculation only when the changing result is genuinely helpful; a constantly changing result can be distracting.

When the calculation produces an object, configure a validation path only when you need to validate a particular value within it. Keep object-based calculations well documented for the people who maintain the service.

Let people change a value only when that is intended

By default, a pre-filled value can be allowed to change. For calculated components, decide explicitly whether the person should have that control.

If a change is allowed, test the full cycle: calculation, person override, upstream answer change, reset, return to the page, and resume from a draft. Explain any non-obvious reset before it happens.

Present the result clearly

Calculated components support the same content formats as information components, including standard content, expandable detail, inset content, important messages and panels. Choose a format that conveys the importance of the result without overemphasising ordinary information.

Use Markdown for readable formatting and Liquid to include the calculated result in a clear sentence:

## Your estimated total

Based on the information you provided, the estimated total is **{{ estimated_total }}**.

The person should understand what the result means, what inputs influence it, and whether it is final or only an estimate. Do not use a calculation to make a decision that cannot be explained or challenged through the service’s normal support route.

Include the right information in review

On a review page, decide whether the calculated component is helpful as a normal label-and-answer row, better as full-width content, or unnecessary. If it influences a person’s submission, they should be able to see and understand it before continuing.

Use a custom review value where the stored result would otherwise be cryptic. Do not expose internal codes, implementation notes or raw data structures in the person-facing review.

Handle validation and visibility carefully

Calculated components can be required and can use conditional validation. Use validation when an intended result must exist before the journey proceeds, not to compensate for a fragile calculation. Give a specific error message that tells the person what they need to change or check.

For visibility, prefer a choice reveal for a small same-page follow-up and a page flow condition for a whole step. Use component-level visibility only for specialised cases, then test both the visible and hidden state and a resumed draft.

Publish checklist

• The component ID describes a single stable value.
• The calculation works with normal, missing and changed upstream answers.
• A person can tell whether the displayed result is final, estimated or informational.
• Any editable calculated value has clear change and reset behaviour.
• Dependent values reset when their controlling answer makes them invalid.
• The review page shows the result in a meaningful way where needed.
• Conditions, actions and templates using the calculated value have been retested.

Related guidance

• Shared component settings
• Information components
• Write Liquid templates
• Use conditions and branching