Review and approve a case

This service pattern helps users to make sure case work and decisions are accurate, transparent, consistent, comply with policy, meet legal and/or ethical standards.

Users involved

For the purpose of this pattern we have detailed two generic roles that are intended to be broadly applicable across multiple services/processes:

• Case worker: Officers who assess and validate cases

• Reviewer: Senior officers who review and issue decisions or officers who are authorised to issue decision

The pattern allows a reviewer to check the work of the case worker who completed the initial assessment. The reviewer can make minor corrections, add comments for feedback or training, and either approve the case or return it for more work.

When to use this pattern

Use this pattern to help users to conduct a review of a case and finalise a decision, for example when:

• a manager needs to approve a planning officer's reasoning and recommendation.

• a senior staff member needs to quality-check a colleague's work as a final step before submitting a decision.

• an audit trail of who has reviewed and approved a decision is required.

When not to use this pattern

Do not use this pattern for:

• Informal peer review. Use a simpler workflow if you only need a colleague to give feedback without a formal sign-off.

• Incomplete assessment. Don’t start the review process until the case work is completed and all the information needed for sign-off is available.

How it works

The review process is broken down into 3 main steps: Understanding the case, Conducting the review, and Preview and finalising a decision.

Step 1: Understanding the case

Give reviewers a case summary with the key information and the case officer’s recommendation in one place. This helps them understand the case and its context before they check the details.

User needs

As a reviewer…

• I need to see all the case information in one place, so that I can understand the context of the review.

• I need to see the case’s details and proposal clearly, so that I know what I am being asked to approve.

• I need to have reference information on hand, so that I can easily check details side-by-side.

• I need to be able to quickly cross-reference, so that I can understand what parties are interested in the case.

Recommended components and patterns

• Use Tabs to let the reviewer switch between different parts of the case, like 'Case details', 'Constraints', and 'Documents'.

• Use a Table to display key dates, contacts, or reference numbers in a scannable format.

• If the service uses location data, consider embedding a map view (work in progress).

Step 2: Conducting the review

The reviewer must be able to work through the assessment in detail. Break the review tasks into separate, logical sections.

Allow reviews to navigate between sections as they need to, they may not work in a linear way.

Provide functions in each section for the reviewer to agree, make a minor correction, or return to the case officer with comments.

Any sections being returned to the case worker should be collected and returned together at the end of the review process.

User needs

• I need to see the details of each assessment task, so that I can check the evidence and reasoning.

• I need to see the task has been marked as completed, so that I can track my progress and see what is left to do.

• I need to be able to make small amendments directly, so that I can fix minor issues quickly without sending the case to the case worker.

• I need to be able to agree or return a section of the case, so that my decision is recorded.

• I need to add comments when I return a task, so that the case officer understands what they need to change and why.

Recommended components and patterns

• Use an Accordion or separate pages to break the review into manageable sections.

• Use Tags to show the status of each section, for example Completed or Awaiting changes.

• Provide clear Agree and Return with comments actions for each section.

• Use an Edit function for making minor corrections without returning the case.

• Use a Text input or Textarea for adding comments and feedback for case officers.

Step 3: Preview and finalising a decision

This is the final step where the reviewer's decisions will be either returned to a case worker or finalised. Before they do this, they are able to see a summary of the outcome at this point. This includes the original recommendation, a log of any changes made, and their final decision.

This gives the reviewer one last chance to check the case before the decision is finalised and published. The case officer should be notified only after the reviewer completes this final stage.

User needs

• I need to see a summary of my review actions, so that I can be confident in my final decision.

• I need to formally accept the recommendation or return the whole case, so that a final decision can be issued or further amendments can be made.

• I need to be able to add a final comment, so that I can provide overall feedback or training notes if needed.

Recommended components and patterns

• Use a Status tag to keep track of your progress and see what is left to be done.

• Provide clear final actions for managers to select, such as Agree and Return with comments.

• Show an Audit log of all actions and comments from both the case officer and reviewer to ensure transparency.

Research on this pattern

This pattern is currently being tested as part of the Back Office Planning System (BOPS) project. We're using it in the private beta phase.

When we first designed BOPS, we used the GOV.UK Design System as a basis to create a step-by-step process for planning officers. This format works well for tasks like validation, consultation, and assessment, as it helps officers focus on one task at a time and reduces mistakes.

However, we found that reviewers work differently. They need to review cases from a broader perspective, not in a linear, step-by-step way. We observed how reviewers were using the first version of the review stage on BOPS at their desk in council offices. The original format was similar to filling in a form. We learned that they found this too administrative and felt it required too many clicks.

Based on this feedback, we redesigned the review pattern. We then tested the new design with planning officers from different local authorities. The current version of the review process is based on this user research. We learned that reviewers need:

• a clear overview of a case

• the ability to make small corrections

• a way to add comments for case improvements and training purposes

Our usability testing showed that breaking the review tasks into separate sections in one page makes the process more consistent and efficient.