Resolve by domain key
A caller that knows only orderId resolves the right row in one atomic statement, with no lookup of the escalation id first.
The situation
The warehouse system emits “order ORD-9 shipped”. It knows the order id, not the Long Tail escalation id, and a find-then-resolve pair would race with anyone else acting on the row.
The recipe
const result = await lt.escalations.resolveByMetadata({ key: 'orderId', value: 'ORD-9', resolverPayload: { shipped: true, carrier: 'acme-freight' }, metadata: { outcome: 'shipped' },});if (result.status === 404) { // no pending escalation for this order}ltc esc resolve-by-meta orderId ORD-9 --data '{"shipped": true}'The lookup rides the GIN index on metadata. The statement picks the highest-priority pending row carrying the pair and resolves it.
The guarantee
Find and resolve are one statement, so there is no window for the row to change between them. RBAC is enforced in the SQL WHERE clause. A row parked by conditional wakes its workflow with the payload, and the optional metadata patch records the outcome in the same update. See Faceted routing.
Related patterns
Resolving from anywhere
Resolve by signal key
A webhook that knows the deterministic signal id resumes the exact waiting workflow, with no id lookup and no facet to duplicate.
Resolving from anywhere
System ingress ignores claims
A person's claim blocks other people resolving by id, while webhooks resolving by signal key or domain key act for the process regardless.
Analytics
The entity is a shared facet
Roles that declare the same entity key form that entity's system. One dial per role, and every analytics query can scope to the whole journey.
Resolving from anywhere
One row, many resolvers
A person, a service, an operator, an agent or a machine can resolve the same row. The workflow receives the same typed answer either way.
