Use a Review action to pause a service for one or more reviewers to accept, return or cancel it. It creates a deliberate approval step: reviewers receive an invitation, see the approved review information and choose from the actions you allow.

Design the review process with the operational team before configuring it. Agree who may review, what they can see, how many approvals are needed, what happens when work is returned, and who handles stalled or cancelled reviews.

Design the approval route

The review name is visible in the journey and can appear in a task list. Write it as a clear status, such as “Manager approval” or “Quality check”, rather than a technical action name.

flowchart TD
  A[Service information is ready] --> B[Review action]
  B --> C[Invite reviewer or reviewers]
  C --> D{Reviewer decision}
  D -- Accept --> E[Continue approval route]
  D -- Return --> F[Person updates and resubmits]
  D -- Cancel --> G[End or route for follow-up]

Choose the action’s trigger after all information a reviewer needs is ready. Do not start review before required validation, document generation or essential checks have happened.

Configure a review

1. Add a Review action from Page actions or the appropriate workflow step.
2. Set a stable Action ID and a plain-language Review name.
3. Specify the reviewer invitation recipients and, if useful, matching recipient names.
4. Choose how many reviewers must accept: one, a specified number, or all reviewers.
5. Decide exactly which fields reviewers need to see.
6. Set the permitted reviewer actions and make the button labels describe their outcome.
7. Add instructions and notification content.
8. Test accept, return and cancel with representative reviewer accounts in QA.

For multiple reviewers, make the approval threshold explicit. “Any one”, “two reviewers” and “all reviewers” lead to materially different operational outcomes; test them with the actual number of invitees.

Show only the information needed

By default, a review can show all fields. Limit the display to selected fields when reviewers do not need the full submission. This is often the better choice for privacy, faster decisions and clearer reviewer screens.

Use Fields to show the reviewer to select the relevant information, and optionally show page titles so reviewers understand the context. Review the resulting screen from the reviewer’s perspective, not only the service author’s perspective.

Do not include sensitive information simply because it was collected. If a reviewer needs a derived result rather than raw data, use a preceding Assign action or a short review instruction instead.

Write instructions and controls

Additional review data text content appears with the review information. Use it for concise decision guidance, policy references and the evidence a reviewer should consider. Review actions intro text content appears before the decision controls; use it to explain what accepting, returning or cancelling will do.

Write the content in Markdown unless raw HTML is genuinely necessary. Keep the instructions useful without turning the review screen into a manual. Use clear headings and short lists for longer checks.

Reviewers can be allowed to:

Custom button text should describe the consequence. For example, “Approve request” is clearer than “Continue” when approval is the reviewer’s decision.

Handle returned work carefully

Decide whether a returned service must have a changed answer before it can be resubmitted. Requiring a change can prevent an unchanged loop; allowing resubmission without a change may be appropriate where a reviewer’s comment was informational or an external issue has been resolved.

Test the whole return route: reviewer comment, user notification, reopened information, corrected answer, resubmission and renewed invitation. Confirm that the reviewer can identify what changed where the process needs that context.

Configure notifications deliberately

The review action can send invitations, acceptance, return and cancellation notifications through the configured email method, or not send a notification for a particular event. Map recipients, templates and variables separately for each stage; a correct invitation does not prove the return or cancellation message is configured.

Use reviewer email expressions that resolve to the intended people. If you supply names, keep them in the same order as the email addresses. Keep notification content brief and avoid including sensitive submission details in messages or subjects.

For template-based notifications, check every template ID, variable and attachment mapping. For direct email notifications, review sender, recipient and reply-to behaviour. Test the delivered messages in QA for accept, return and cancel outcomes.

Operate the review process

Name an owner for delayed reviews, failed notifications and reviewer access problems. A review action creates a workflow state; it does not replace an operational process for clearing a queue or escalating overdue work.

Document the expected service-level time, reviewer group, decision criteria and escalation route alongside the service. Review those details whenever the organisation changes roles, policy or notification templates.

Test checklist

• The review starts only after all required information is available.
• The review name and task-list status are understandable to the person.
• Reviewers see only the fields they need.
• Approval threshold matches the intended policy and number of reviewers.
• Accept, return and cancel actions have clear labels and tested outcomes.
• The returned route allows or requires changes according to the agreed process.
• Invitation, acceptance, return and cancellation notifications each work in QA.
• Delays, failed delivery and reviewer access have an operational owner.

Related guidance

• Shared action settings
• Task list services
• Review and completion pages
• Write Liquid templates