Use a Delete action to remove previously collected values from the current journey. It is useful when an answer becomes irrelevant, when a person changes direction, or when information should not remain available to later pages and actions.

Deletion is a service-design decision, not just a tidy-up step. Before configuring it, identify every page, condition, document and integration that could use the value afterwards.

Decide exactly what should be cleared

You can clear selected fields or clear all fields associated with one or more pages. Prefer the narrowest scope that meets the requirement.

flowchart TD
  A[Person changes an earlier answer] --> B{Which values are no longer relevant?}
  B --> C[Clear named fields]
  B --> D[Clear fields from a no-longer-relevant page]
  C --> E[Continue with only relevant information]
  D --> E

Clear named fields when only a small number of dependent values must be removed. Clear all fields on a page when the whole page belongs to a route that no longer applies. Do not clear a wider page simply because it contains one outdated answer.

Configure a Delete action

1. From Page actions, add a Delete action.
2. Give it a stable ID and an explicit name, for example clear_postal_contact_details.
3. Choose a trigger that runs after the decision making the data irrelevant has been validated.
4. Add the field IDs to Delete fields, or select the pages in Delete all fields on pages.
5. Add execution conditions if deletion should happen only for a particular route.
6. Test the journey before and after changing the controlling answer.

The action removes answers, not the component definitions. If the person returns to the relevant page later, they can answer the fields again.

Use conditions to protect relevant answers

Pair a Delete action with the same business rule that makes a value irrelevant. For example, when someone changes their preferred contact method from email to telephone, a condition can run an action that clears the email detail only when the new choice is telephone.

Keep the condition positive and readable. A name such as contact_method_is_telephone is easier to audit than a broad inverted condition. Review the action’s trigger and condition together; an action that runs too early can erase information before another action has used it, while one that runs too late can allow obsolete information to be included in a document or message.

Consider repeat visits and drafts

People may go back, revise an answer, leave a draft and return later. Test those behaviour patterns deliberately.

• Enter values in the fields that might be cleared.
• Take the route that makes them irrelevant.
• Continue to the review and completion steps.
• Go back and choose the original route again.
• Resume a saved draft and check that the visible fields and stored values agree.

If the service needs an audit of a prior response, do not rely on a delete action. Decide and document where that audit information is retained before designing the route.

Protect downstream actions

An action that sends a message, produces a document or calls another service may depend on data that a Delete action removes. Put prerequisite actions first, and place deletion only after the value is no longer required. Where appropriate, test a document or message after the route changes to make sure it does not display an empty label, stale value or misleading sentence.

Example: clear an alternative address

A service asks whether correspondence should go to a different address. If the person changes Yes to No, a conditional Delete action clears the alternative-address fields after the updated answer has been validated. The review content and completion message then use the main address only.

Test checklist

• The action clears only the fields or pages that have become irrelevant.
• Its trigger runs after the decision that justifies deletion.
• Conditions prevent deletion on routes where the information remains needed.
• Later actions, documents and review pages do not expect cleared values.
• Going back, changing an answer and resuming a draft have been tested.
• The service has an agreed approach where retention or audit information is required.

Related guidance

• Shared action settings
• Use conditions and branching
• Page navigation and journey behaviour
• Review and completion pages