Give a shared request one current owner
A queue can be visible to several people without making responsibility clear. If two reviewers open the same unassigned request, both may believe they have taken it. A later timestamp does not explain who should continue or what the other person should do.
This fictional example follows a technical enquiry shared between colleagues working different hours. It focuses on a simultaneous ownership decision. It does not assume that everyone is online together or that an incoming request creates a response-time promise.
Reproduce the two successful claims
Request Q-52 is ready for technical review and has no current owner. Hana and Marek both load the queue while that is true. Each sees a button labelled “Take review.”
Hana presses it first. Her screen says the request is assigned to her. A moment later, Marek presses the same button on his older view and also sees success. The stored record now names Marek, because the second save simply replaced the first owner. Hana continues preparing a response without knowing that the ownership record has changed.
The notes and request material are still present. The failure is that two independent confirmations contradict the rule that only one reviewer should own this task at a time.
Agree the business rule
For Q-52, the organisation approves these rules:
- An eligible reviewer may claim a request only while it is ready and unassigned.
- A successful claim creates one current owner.
- A stale claim must explain that the request is already assigned, rather than overwrite the owner.
- The current owner may hand it back with a reason; the next reviewer can then claim it.
- Transferring responsibility through another authorised route is a separate operation.
The rule does not prevent colleagues from discussing the request. It defines who is accountable for the next review action. If the business needs joint review instead, the model should represent that deliberately.
Put the check at the authoritative update
The old interface checked whether Q-52 was unassigned when the page loaded. That observation can become stale before the person acts. Hiding or disabling a button based on that old observation cannot prevent a competing update.
In the inspected fictional application, the supported correction performs the eligibility and unassigned-state check as part of the authoritative claim operation. The operation changes the owner only when those conditions still hold. The result distinguishes a successful change from a claim that did not change the record.
A database-backed implementation may use a conditional update or another suitable concurrency mechanism. PostgreSQL's transaction-isolation documentation describes how competing updates are handled and when conditions are re-evaluated. The appropriate implementation depends on the actual database, isolation level and application. The business requirement should not be reduced to a universal code snippet.
Repeat the competing action
The test resets an invented request to the initial state and gives both reviewers the same unassigned view. Hana claims it successfully. Marek's stale attempt does not change the owner and receives this fictional message:
Hana has taken this review. Refresh the request to see the current work; your claim did not change its owner.
The queue and detail view both name Hana. Marek can read the information his role permits, but the application does not show a successful ownership confirmation. The record of the attempted claim supports investigation without adding the request's private contents to a general notification.
A second fixture deliberately overlaps the operations. Both claim requests reach the service before either reviewer receives a result. An ordinary read followed by an unconditional write could still let both read “unassigned,” even if that read happens immediately before the write. Moving the old check closer to the save is therefore insufficient.
For this fixture, the assumed inspected implementation uses a supported conditional database update. Hana's operation changes the unassigned row while its transaction is still open; Marek's competing operation waits. After the first transaction commits, the second operation rechecks the condition against the current row and makes no change. The observed fictional result is exactly one successful claim and one no-change response, with Hana as the sole owner. Reversing which operation reaches the row first makes Marek the winner without changing the one-owner rule.
A control request Q-53 is already assigned to a third reviewer. Neither stale page nor a direct claim attempt by these accounts takes it over. The corrected operation has not turned every claim into a forced reassignment.
Complete the handback
Hana then discovers that she cannot continue during the agreed review window. She uses the supported handback action and records “Needs the product specialist's next review session.” Her saved working note remains with Q-52, clearly separate from a final response to the customer.
The application records the handback, clears the current owner and returns the request to the eligible queue. Marek refreshes, reads the handback reason and claims Q-52. This time the conditions are true, so his claim succeeds. The current owner is Marek; Hana's earlier work and the handback remain understandable.
The resolved sequence is therefore one successful claim, one rejected competing claim, an explicit handback and one later successful claim. It is not two concurrent owners hidden behind a last-saved value.
Keep time context useful
Record event times unambiguously and label the display context when people work across locations. The audit sequence should be based on authoritative events, not an assumption that a colleague's device clock proves which action won.
Working hours belong in the operational arrangement. A request arriving outside one person's hours may remain unassigned or follow an agreed alternative route. It should not appear owned merely because a notification was sent. Similarly, a customer's requested deadline and an accepted response commitment are different facts.
The inquiry-time note examines those timing fields. Here, the ownership operation and handback are the main controls.
Hand over the rule and the evidence
Retain the approved ownership model, eligible roles, competing-claim fixture, feedback wording and handback check. The next maintainer should know what must remain true when the queue layout or provider connection changes.
The test does not establish every concurrency property of the application. Other operations, such as approving a quotation or replacing a document, need their own rules. It does establish the bounded outcome for claiming and returning this review task.
Use a fictional shared request to discuss custom software or workflow automation. The handover sheet helps identify who owns the next decision before the interface is built.