Born-assigned hand-off
The next row is created already assigned to a named person, in the same write that creates it. It lands in their list with no claim step.
The situation
A reviewer approves an order, and the rework step should go straight to that same reviewer. Waiting for them to find and claim it in the queue wastes time and lets someone else take it.
The recipe
const approval = await conditional<{ approved: boolean; $resolution?: EscalationResolution }>( `approve-${workflowId}`, { role: 'order-reviewer', metadata: { orderId } },);if (!approval || !approval.$resolution) return { type: 'return' as const, data: { orderId } };
const rework = await conditional<{ done: boolean }>(`rework-${workflowId}`, { role: 'order-reviewer', subtype: 'rework', metadata: { orderId }, assignee: approval.$resolution.resolvedBy, durationMinutes: 60,});assignee writes assigned_to in the same insert that creates the row. Add durationMinutes and the row is born locked to that person for the window, exactly as a claim would lock it.
The guarantee
There is no moment where the row is visible and unassigned. Without durationMinutes the assignment is a durable pre-assignment: it shows in the assignee’s list and others may still claim it. With it, the row is a live claim from its first instant. See Conditional.
Related patterns
The escalation boundary
Know who resolved it
The resolver's identity rides the wake as $resolution and lands on the row as resolved_by, so follow-on work can go to the same person.
Identity
One-time user
Route one item to one named person with a self-scoped membership; they see and answer exactly that form and nothing else in the queue.
Resolving from anywhere
A claim is a work lock
A claim names a holder and a window. While the window is live nobody else can resolve the row, and when it lapses the row is back in the pool.
The escalation boundary
One crash-safe write
The row, its facets and the resume timer commit with the workflow's checkpoint in one write. A crash leaves all of it or none of it.