Use a Fetch form action to retrieve a submission from the same organisation for use in the current service. It can retrieve a specific submission, the latest completed submission for a user, or the latest completed submission for a group.

This action can expose personal or operational information across journeys. Start with the smallest data scope and the normal access restriction. Expand access only after a documented privacy, security and business review.

Decide what must be fetched

Choose the lookup basis that matches the business need:

Choose No fields when only submission metadata is required, Selected fields when the current route needs a small known set of values, or All fields only where the full context is genuinely needed. Selected fields are usually safer and easier to maintain.

flowchart LR
  A[Current service has a permitted reference] --> B[Fetch form action]
  B --> C{Access and filter checks}
  C -- Allowed --> D[Return minimum required data]
  C -- Not allowed or no match --> E[Follow clear alternate route]

Configure the action

1. Add a Fetch form action from Page actions.
2. Set a stable Action ID and a name that identifies the purpose, such as retrieve_previous_application.
3. Select Fetch by and supply the corresponding submission, user or group template.
4. Set the target service if it differs from the current service.
5. Choose the smallest appropriate field scope.
6. For selected fields, list the exact field IDs or permitted context values to return.
7. Add a filter field and value where the retrieved submission needs an additional business check.
8. Keep the normal access scope unless a formal approval authorises broader access.
9. Test allowed, denied, no-match and incorrectly scoped requests in QA.

Use field selection and filtering

Use Selected fields to return only the values that a later page or action needs. This reduces unnecessary data exposure and makes it clear which fields the current service relies on. When field names change, review the fetch action alongside the affected service.

An optional Filter field and Filter field value adds an extra match requirement in the target service. Use it to enforce a known relationship, such as a case reference or organisation identifier. It is not a replacement for access control; it is an additional business check.

Do not fetch all fields because it is convenient during development. That can expose values to templates and actions that do not need them and makes privacy review much harder.

Keep access scope narrow

By default, the action can retrieve only submissions the current runtime user may already access. This is the correct setting for most services.

The broader Access scope option can allow access to any user’s submission in the organisation. Use it only where there is a clear, approved role and process that needs it. Document the reason, restrict which values are fetched, provide an audit route, and test with accounts that should and should not have access.

Important: A valid submission ID is not, by itself, permission to show someone’s data. Keep the normal access restriction unless the organisation has explicitly approved a wider scope.

Handle no match and stale data

The latest completed submission may not be the one a person expects, and a supplied reference can be missing or stale. Design a no-match route that tells the person what they can do next without revealing whether another person’s submission exists.

Test what happens when the target submission is incomplete, closed, changed, belongs to a different user or group, or contains an optional selected field that is blank. Review any content that displays fetched data to ensure it remains accurate and understandable.

Test checklist

• The fetch basis matches the business relationship between services.
• The target service and filters identify the intended submission.
• The action returns the minimum field set needed.
• Default access restrictions remain in place unless wider access is formally approved.
• No-match and denied-access paths are clear and do not disclose sensitive information.
• Field IDs, optional values and changed target submissions have been tested.
• QA tests use accounts with both permitted and non-permitted access.

Related guidance

• Set form status actions
• Authorization actions
• Shared action settings
• Write Liquid templates