Two Reviewers Decide at Once: How Should a Document Workflow Respond?
Handle competing decisions, enforce reviewer eligibility, and preserve the review history
Published
Two procurement reviewers open the same replacement insurance certificate. The review needs one decision. Maya approves it while Leon is still checking the dates; seconds later, Leon submits a rejection. Both screens began with an open request, but only one submission can finish that review.
When a review has completed, refresh its current state and explain the recorded outcome instead of automatically resubmitting the competing decision. Preserve the second reviewer's concern and offer a clear next action: add a comment, notify the responsible owner, or request a follow-up review. A disabled button helps prevent double clicks; the server must also enforce the review's completion rule when requests compete.
Separate eligibility, completion, and business outcome
These are three different decisions. Someone may be allowed to review, the review may have collected its required responses, and the document may still need correction. Make those meanings visible before deciding which downstream action should run.
Who may act?
Apply document and site permissions, plus any approval-group requirement. Assignment and an open browser tab do not establish continuing authority.
What finishes the review?
Define the required responses and stages. A single decision, two independent sign-offs, and sequential procurement and risk reviews are different process rules.
What happens next?
Evaluate the recorded outcomes under the business rule. Approval may enable acceptance; rejection may leave a renewal unresolved and request corrected evidence.
Define whether a group list identifies everyone eligible to act or represents separate required sign-offs. If procurement and risk must both approve, express that rule through distinct required stages or responses. Also specify whether the reviewers must be different people and how a rejection affects the result.
A response count alone does not describe the full approval policy. Show “review completed” separately from the application's approved, rejected, or correction-required outcome. Two valid responses can satisfy a collection requirement while still disagreeing about the document.
Keep the submission tied to the exact review
Display the document being reviewed, its submitted revision, review stage, current state, and the action the person is taking. Submit using the same workspace, document, and review context. Refresh that context after a change of file, assignment, or review stage.
The server should check eligibility and review state as part of accepting the decision. A client-side check followed by an unprotected write leaves a gap in which another submission can finish the review. Use the platform's supported state checks or conditional operations, and make the accepted decision and completion transition consistent.
Give each response a useful recovery path
| Result | Client action | What the reviewer sees |
|---|---|---|
| Accepted decision | Retain the returned decision ID and reload the review and its decisions. | The recorded response and whether further review is required. |
| Conflict or stale state | Stop automatic replay. Read the conflict reason and refresh the review; retain unsent feedback as unsent. | What changed, whether the review completed, and the available comment, notification, or follow-up route. |
| Authorisation failure | Refresh access and assignment information. Resolve eligibility through the authorised owner. | A clear explanation that the action is unavailable under current permissions. |
| Timeout or lost response | Query the review and recorded decisions before offering another submission. | The submission outcome is being checked, with further action offered once it is known. |
An HTTP API may report this situation as 409 Conflict. HTTP semantics defines that response as a conflict with the resource's current state; it does not identify the business reason on its own. Read the response and refresh the record before telling the reviewer that someone else completed it. Show an attempted decision as recorded only after its acceptance is confirmed.
A timeout is different: the request may have succeeded before the response was lost. Query both the current review and its decisions, including later result pages when relevant. If the outcome remains uncertain, keep that uncertainty visible and route it for reconciliation instead of assuming the user's response was accepted or sending it repeatedly.
Work through the competing supplier decisions
This fictional example uses supplier file VEN-1042, a replacement certificate, and a review configured to finish after one eligible response. It illustrates a client interaction; it does not prescribe the approval rule for every supplier.
Both reviewers load the same open review
Maya and Leon see the same certificate and review ID. Each can inspect the evidence and prepare a response. Their screens identify the review as awaiting a decision.
Maya's approval completes the review
Her submission is accepted and the refreshed record shows the completed review and approval. The application applies its acceptance rule and identifies the certificate as current.
Leon's later rejection receives a conflict
The client reloads the record and explains: “This review has already completed. Your rejection was not submitted.” Leon can see Maya's recorded outcome if his permissions allow, while his draft feedback remains clearly separate.
Leon sends the concern to the review owner
The client offers “Send concern to review owner,” carrying forward Leon's draft feedback and the certificate reference. Leon chooses that action. Once the concern is saved, the screen confirms it and shows whether the notification was queued or delivered; it still identifies his rejection as unsubmitted. The owner assesses whether to pause use, request a corrected certificate, or open another review. The earlier approval remains in the history.
For a review that requires more responses, two near-simultaneous submissions can both be valid while completion requirements remain unsatisfied. Test that policy separately. A rule that protects completed reviews should still allow the intended collection of multiple responses before completion.
Offer a comment, notification, or new review deliberately
The client can preserve the second person's input through a different action when the workflow permits it. These actions have different effects, so give each a clear label and explain what will be saved. Do not silently turn a rejection into a comment or imply that notifying someone changed the approval.
Add a comment
Use a document discussion or linked concern record that accepts post-review feedback. Keep the author, time, original review, affected revision, and intended decision. Confirm that the comment was saved and that the completed outcome is unchanged.
Notify the responsible owner
Send a notification with a link to the saved concern and assign someone to assess it. Track notification status separately from the concern's resolution. A sent message does not establish that the issue was reviewed or corrected.
Request another review
Use this when the concern needs a fresh decision, corrected evidence, or formal reconsideration. Link the new review to the earlier one and name the authority that can open it. Record any temporary pause in use as an explicit business action.
These options can work together: save a concern, notify its owner, and let that owner start a follow-up review if needed. Check current permissions for the chosen action. If the comment destination is also closed, offer an authorised alternative rather than replaying the same failed request with a different label.
Make retries safe for the follow-up action too. If a notification times out after the concern was saved, retry or reconcile that delivery against the same concern. Avoid creating a second comment or opening another review each time the client reconnects.
Keep the concern connected to its resolution
- 1 · Refresh
Show the recorded state
Load the accepted decisions and explain why the original action is no longer available.
- 2 · Assess
Route the new concern
Give the responsible owner the feedback, affected revision, and reason for another review.
- 3 · Follow up
Link the new decision
Record the authorised correction or later review with its relationship to the earlier outcome.
Keep approvals, recommendations, acknowledgements, and comments distinct in the interface and define which affect the process. Connect the saved concern to its owner, assessment, and eventual outcome. The history should explain both the initial decision and what happened when new information arrived.
Retain the decision identity, author, time, response, and relevant document context. Preserve any delegation, correction reason, or new-review relationship too. Apply the organisation's access and retention rules to those records. Preventing a late decision from overwriting a completed review is a concurrency control; storage-retention requirements are a separate governance decision.
Test the paths that ordinary demonstrations miss
- Submit competing responses to a review that needs one decision; verify the accepted record, conflict message, and absence of a second saved decision.
- Repeat with a multi-response process and verify its intended completion and business-outcome rules.
- Change approval-group eligibility while a review screen is open, including the identity refresh used by the deployment.
- Drop a successful response and check that the client reconciles the record before another attempt.
- Open an earlier artifact or a superseded review and confirm that the interface identifies its historical context.
- Raise a concern after completion and follow it through the authorised correction or new-review process.
- Save the second response as a comment through its intended destination; confirm that it does not count as an accepted approval or rejection.
- Fail a notification after the concern is saved, then reconcile delivery without duplicating the concern or its follow-up review.
- Confirm that downstream publication or supplier acceptance follows the recorded outcome and runs through the intended application rule.
Make the recorded outcome and next step clear
A reviewer should be able to understand what was recorded, why a later action was refused, and how to raise new information. Combine server-enforced completion rules with a state-refresh path and explicit options to comment, notify an owner, or request another review. Preserve the accepted decision and give the second person's concern a visible path to resolution.
Technical guidance reviewed: November 13, 2026. Platform-specific behaviour is sourced in the asides; the recovery paths and supplier scenario are illustrative application design choices.