A notification does not own the work

It has been sent to someone

The handler has sent the catalogue problem to a specialist. The specialist has received a message. Neither is now watching for the mapping decision. This can happen without a delivery failure: the handler reads escalated as a transfer, while the recipient reads the notification as information. The supplier code still matches two catalogue items. Before automating more of that handoff, I would want to know who remains responsible until somebody actually accepts it.

Asking a person to take work and having them accept it are separate events. A notification can record the first, but it does not establish the second. Combining them gives a busy inbox an optimistic role in the workflow: every delivered request appears to have found an owner. An absence, an unclear request or a message read between other tasks is enough to expose the difference.

Google’s SRE incident guidance says handoff should be explicit, acknowledged and communicated so responsibility is clear. [1] The same ownership distinction is useful for a catalogue exception even though it needs a much smaller process. While the specialist decides whether to accept, somebody still has to notice if the case remains unresolved and arrange another path.

Name the work being handed over

In the original example, case H18 concerns a supplier code that maps to two possible catalogue items. Handler A can establish that the automatic mapping is ambiguous but cannot choose the intended item. The handoff asks specialist B to identify the correct mapping from the supplier record and approved catalogue evidence. “Please investigate” is weaker: it leaves B to rediscover both the problem and the decision needed.

The packet should contain the relevant source reference, observed ambiguity, actions already attempted, current state and next decision. Include the consequence of choosing incorrectly: future stock updates could attach to the wrong item. Keep secrets and unrelated customer data out of the packet. More context is useful when it reduces uncertainty about the task; a large forwarded thread can instead make the essential question harder to find.

The packet should keep “matches C11 and C12” separate from “probably means C12”. The first is what the lookup found; the second is a hypothesis unless something supports it. A specialist needs that distinction to decide where to investigate. If the handoff quietly promotes the guess, choosing C12 later can look like careful execution of a decision already made rather than the unsupported step it actually was.

Also state what B is allowed to do. They may be asked to recommend a mapping, update the approved mapping record or resume the paused import. Those are different scopes. Accepting the research task should not implicitly authorise every downstream effect the original workflow could perform. The handoff carries responsibility for a defined next action, not a vague transfer of all possible authority around the case.

Keep the owner while the offer is pending

The model gives H18 an owner, offered recipient, offer identifier, revision and state. At revision 5, owner A offers it to B as offer7. The owner remains A while the state is offered. That does not require A to solve the specialist question personally; it means A is still responsible for noticing if the request has not been accepted and arranging another path before the work is abandoned.

Acceptance is a conditional transition. B accepts offer7 against revision 5; if that is still the current offer, the record moves to owner B and revision 6. A repeat click against the old revision changes nothing. A real implementation can use an atomic conditional write rather than reading the row and later overwriting it unconditionally. PostgreSQL documents the conditional UPDATE and affected-row behaviour supporting that pattern. [2]

The downloadable SQLite model retains A as owner while the offer waits and changes ownership only when the current acceptance succeeds. The rejected repeat is worth inspecting: B may have clicked twice without intending another transfer, so the second request should report the current outcome rather than create another assignment. These local transitions define the rule a notification link must use. Delivering the link and arranging duty cover remain separate work; neither is supplied by the row change.

A cannot remain the answer forever if their shift ends. The process may need a duty owner or a named queue whose duty arrangements are explicit. What has to survive is the responsibility to notice the unaccepted offer and arrange another path, with a deadline appropriate to the consequence. That allows the preferred specialist to be unavailable without letting a pending invitation become a place where the work simply waits for everybody to remember it.

Old invitations should not transfer current work

Suppose A withdraws offer7 and offers H18 to C as offer8 at revision 8. B later opens the old notification and accepts. A check of the offer identity and revision rejects that stale acceptance: offer7 at revision 5 is no longer current. Without the condition, the old link could transfer work away from the replacement offer. The invitation must therefore be validated against current case state when accepted.

A helpful response explains the change: this offer is no longer available, and the case is now assigned or offered elsewhere as permitted by the person’s visibility. It should not claim success and then rely on a background reconciliation to sort out two owners. The recipient can still contribute relevant evidence through the supported route, but an old link should not silently recreate the old assignment.

Changed context can require another review even if the offered recipient remains the same. If the supplier record is corrected while B reads it, the mapping question may have a different answer. The acceptance screen should show the current case or identify that its evidence changed, and the eventual mapping update should use the relevant revision boundary. Accepting responsibility is not a reason to ignore later changes to the thing being decided.

Returning work needs a similarly explicit path. If B cannot resolve the ambiguity, record what was checked, what remains unknown and who accepts the return or owns the next escalation. A “rejected” status with no accountable destination merely moves the gap to another column. The person receiving it should gain evidence from the specialist’s attempt rather than begin the original investigation again.

Ownership is not permission to rewrite history

Once B owns the case, the mapping decision still needs its evidence and an appropriate change record. Ownership answers who must progress the work. It does not prove a mapping is correct or grant access the person did not previously have. Keep permissions, approval requirements and current source versions in the action path so that a workflow assignment does not become an accidental privilege escalation. Check whether an action is already in progress before changing its owner, too. If A has submitted a mapping update while B accepts, the ownership transition should not encourage B to repeat it as a fresh action. Keep effect status and operation identity with the case. The handoff transfers responsibility for reaching a justified outcome; it does not reset the processing history or establish that no external change has begun.

Completion should name the resulting business state. “Mapping approved as C12 and paused import resumed” is different from “recommendation sent” or “waiting for supplier clarification”. All can be legitimate progress, but only one may satisfy the original next-action request. A case can be handed over successfully and still remain unresolved; avoid collapsing those two achievements into a single done label.

The operator can now distinguish an offer awaiting acceptance, accepted work awaiting a decision, a return and a confirmed resolution. Their ages and consequences matter more than the number of notifications sent. A busy escalation channel might show that problems are being noticed early. It might also show that the automation has become efficient at delivering its uncertainty to other people without an agreement about who will handle it.

For H18, a useful handoff leaves A accountable while offer7 waits, transfers responsibility only through the current accepted offer, and gives returned work somewhere explicit to go. B’s investigation remains useful even if it cannot settle the mapping. Keep that evidence with the case so the next person continues from it. Notification delivery, accepted ownership and a justified mapping can then each count as progress without being mistaken for the same completed job.