Use a Redirect action to send a person to another page, reload the current page, move them back one page, or direct them to an external URL. Redirects are powerful journey controls: use them only when normal page navigation and conditions cannot express the intended route clearly.

Always place a redirect last among actions sharing the same trigger. Once navigation begins, a later action may not run.

Choose the redirect type

flowchart TD
  A[Page action runs] --> B{Redirect type}
  B -- Internal --> C[Another page in this service]
  B -- External --> D[Approved external destination]
  B -- Reload --> E[Current page refreshed]
  B -- Back one --> F[Previous page]

Use an ordinary page condition rather than a redirect when the requirement is simply “skip this page when the answer does not apply”. Conditions keep the flow easier to see and maintain.

Configure an internal redirect

1. Add a Redirect action from Page actions.
2. Give it a clear ID and name, such as send_to_payment_step.
3. Choose Internal and select the target page.
4. Add execution conditions if the redirect applies only to a particular route.
5. Decide whether the person should be able to go back to the redirected-from page.
6. Put the redirect after every prerequisite action.
7. Test forward navigation, browser back behaviour and a resumed draft.

The target must be a valid page in the service. Normal flow restrictions still apply, so a redirect is not a way to bypass pages that the journey design prevents a person from reaching.

Use external redirects carefully

An External URL can use Liquid and must begin with http:// or https://. Use only a controlled, approved destination. Clearly tell the person that they are leaving the service, especially if the next site has a different sign-in, privacy notice or support route.

Do not construct an external URL directly from unreviewed user input. If a value needs to affect the destination, constrain it to a known set and test every result. Confirm that service data is saved at the intended point before the person is redirected.

Use a Redirect fragment only when the target supports a specific, useful anchor. Avoid fragments as a substitute for clear page structure.

Manage back history and transient values

The redirect settings can remove the current page, or all pages since the target, from the person’s back history. Use this only when returning to those pages would create an invalid, confusing or unsafe route. Preserve history by default so people can review and correct answers.

The setting to prevent clearing values on page load should be used only when you understand the page’s transient behaviour. Test the route after reload, back navigation and draft resumption; retaining a value that should reset can be as harmful as clearing a value that the next action needs.

Add query parameters only when required

You can attach paired Query parameter name and Query parameter value entries to the redirect. Use these for a documented integration need, not for carrying sensitive information. Parameters can be visible in browser history, logs and referral data.

Keep names and values aligned in the same order. Test how the target receives them, including blank optional values and URL encoding.

Test checklist

• The normal page flow or a condition cannot express the route more simply.
• The action is last in its trigger sequence.
• Internal targets are valid and every dynamic target has been tested.
• External destinations are approved, clear to the person and use safe input.
• Back-history behaviour matches the journey design.
• Reload and back-one routes do not loop or repeat important actions.
• Query parameters are necessary and contain no sensitive information.
• Browser back and resumed drafts work as intended.

Related guidance

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