Use a Set form status action to reopen or close a specific submission in the same organisation. Reopening makes the target submission editable and incomplete; closing marks it complete and closed.

Changing another submission’s status can alter someone’s ability to work on it. Use this action only as part of a clearly designed workflow with an agreed owner, audit process and recovery path.

Choose the status change carefully

flowchart LR
  A[Approved workflow decision] --> B[Identify exact submission]
  B --> C[Set form status action]
  C --> D{New status}
  D -- Open --> E[Submission can be edited]
  D -- Closed --> F[Submission is complete and closed]

Do not use this action as a general substitute for validation or a review decision. The action changes state; it does not explain the business reason to the person affected.

Configure the action

1. Add a Set form status action from Page actions or the owning workflow step.
2. Set a stable Action ID and a name that describes the business event, such as reopen_for_correction.
3. Set the Submission ID template to the exact submission to change.
4. Specify a target service only when it differs from the current one.
5. Choose Open or Closed.
6. Keep the normal access scope unless a formally approved role needs wider authority.
7. Add execution conditions so the action runs only for the intended decision.
8. Test the changed submission with an appropriate QA user.

The submission ID is required. Do not derive it from unvalidated user input or use a broad lookup result without confirming that it identifies the intended submission.

Protect access and ownership

The normal access scope permits status changes only for submissions the current runtime user can already access. This should remain the default.

The wider access option can affect any user’s submission in the organisation. Treat it as a privileged workflow capability: obtain approval, restrict the action to the appropriate authorised route, document its purpose, and test non-authorised accounts. Do not enable it simply to make a test or integration easier.

Design the person’s experience

When reopening work, explain why it was returned, what needs to change and how the person can resubmit. When closing work, provide a clear completion or status message. Pair the status action with review or notification behaviour where the process needs to inform the person.

Test the target submission after the action runs. Check its actual status, whether it is editable, what the person sees on return, and whether it appears correctly in task lists or operational views.

Test checklist

• The action targets the exact intended submission and service.
• Open and closed are chosen for the correct workflow outcome.
• A clear condition prevents accidental state changes.
• Normal access restrictions remain enabled unless wider access has formal approval.
• The affected person receives an understandable status or return explanation.
• The target submission has been checked after the action in QA.
• Recovery and escalation steps are documented for an incorrect state change.

Related guidance

• Fetch form actions
• Review actions
• Authorization actions
• Shared action settings