Calculated components

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

Calculated components, including saved action results, are read-only content. They do not render an input for the respondent to edit.

If a person should correct a suggested value, use an ordinary input with pre-population and the appropriate change/reset controls. Keep that answer distinct from the calculated/generated suggestion. Test initial calculation, respondent edits, changes to earlier answers, reset, back navigation and resuming a draft.

Present the result clearly

Ordinary 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.

For an ordinary calculated component, use a custom review value where the stored result would otherwise be cryptic. Saved action-result fields bypass content and custom Check answers templates and display their escaped stored value; use the result path/template to save the intended value and its visibility controls to choose who sees it. 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.
Respondent-editable suggestions use a separate ordinary input with tested pre-population 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.

Save a completed action result

Value source → Action result stores a selected result after an existing submission action runs. Choose a result path or Liquid, and set page, applicant-answer and review visibility independently. This is separate from a pre-populated calculation; do not configure both sources. See Saved action result settings and defaults.

Refresh display content while typing

For an ordinary calculated field, prepopDoAjaxRecalculate="true" refreshes both its calculation and infoText display as watched answers change on the same page. With it off, content renders on page display. This live content refresh does not apply to action-result fields or fields inside a Data Grid. Information components also render on page display rather than refreshing as someone types.