Where an automated workflow should hand back to a person

A workflow can run successfully and still leave the wrong person responsible for the next decision. An unfamiliar request lands in a shared inbox, an alert appears in a channel everyone assumes someone else reads, or a retry repeats an action that may already have happened. These are handoff problems. They deserve a design before the ordinary path goes live.

A human handoff should tell a person what needs deciding, provide the relevant evidence and preserve the state of the work while they decide. It should also explain what happens if nobody responds. Start by listing the decisions your automation is allowed to make and the decisions that remain with an accountable person.

Separate uncertainty from technical failure

An incomplete request and an unavailable destination are different problems. The first may need clarification from the requester. The second may need a technical retry after someone checks the service state. Sending both to an undifferentiated failure queue makes it harder for the reviewer to know what to do and may encourage inappropriate retries.

Use a small set of meaningful reasons. Examples might include missing information, conflicting information, approval required and delivery uncertain. Each reason should have an owner and a next action. Keep the categories understandable to the people handling them. A long list of internal error names is rarely a useful review interface for an operations team.

Define the decision before the notification

Consider a fictional workflow that prepares a project after receiving a service request. A familiar category can be assigned to the usual team. An unfamiliar category goes to a dispatcher. The dispatcher needs to choose a team, request clarification or decline the request. That is the decision. “Please check this” is not enough information to support it.

The handoff should include the request identifier, the reason it stopped, the relevant fields, a link to the authoritative record and the allowed actions. Show what has already happened so the reviewer does not accidentally repeat it. If an action will contact someone externally, make that consequence visible before the reviewer confirms it.

Give the queue a named owner

A queue belongs to an operational role, with a backup arrangement when the usual owner is absent. Decide who checks it and at what interval. The appropriate interval depends on the work; a team should choose one it can actually maintain. Avoid displaying an implied urgent deadline that nobody has agreed to support.

Notifications should help that owner find the work. They should not become the only place the work exists. A message can be overlooked, muted or separated from later updates. Keep the current state in a shared record that the responsible person can inspect. A notification should point to that state rather than create a competing version of it.

Preserve the facts that were approved

A reviewer may approve a request and then discover that someone changed it before the action ran. Decide which changes invalidate approval. A correction to a delivery address may matter; a harmless formatting change may not. Make that policy explicit and have the implementation compare the relevant state at the time it acts.

This is particularly useful when several people can edit a record. Store enough context to explain which version the reviewer saw and what decision they made. Do not rely on a vague approved flag with no history. The goal is a record a colleague can understand during an ordinary handover or an investigation into an unexpected result.

Distinguish a retry from a new action

A timeout does not always tell you whether the destination performed the requested operation. Before retrying, the implementer should determine whether the action can be repeated safely and how to recognize a prior result. Stripe's idempotency documentation describes a provider-specific mechanism for retrying requests without performing the same operation twice. Use each service's actual contract when designing your own integration.

The reviewer interface should distinguish “try the same operation again” from “create another item.” Those are different intentions. If the result is uncertain, provide a reconciliation step: inspect the destination record or request history before authorizing another attempt. A generic retry button should not invite someone to guess about an action with external consequences.

Expect repeated events and changing order

An incoming notification can also repeat. Stripe's webhook documentation explains that events may be delivered more than once and are not guaranteed to arrive in their creation order. That example is a useful reason to ask integration-specific questions about event identity and current state. It is not a statement that all providers behave identically.

For a review queue, ask what happens if an event arrives while someone is already considering the same item. Does the queue update the existing item, create a duplicate or invalidate the current decision? Establish the intended behavior and test it. A reviewer should not need to infer which of two similar items represents the latest state.

Design the unanswered path

Every approval request has at least three practical outcomes: approved, rejected and unanswered. Decide what the third outcome means. It might remain pending, move to a backup owner or expire with a visible reason. Automatic approval after silence should only exist if the responsible organization deliberately chose that policy and understands its consequences.

An escalation should add information, not merely repeat the same alert more loudly. Show how long the item has waited, who currently owns it and what action is needed. If the original request has become obsolete, allow it to be closed without performing the action. Keep the closure reason so another operator does not revive it accidentally.

Keep review permissions appropriate

The person receiving a notification is not automatically authorized to approve the underlying action. Match available decisions to the reviewer role and the organization's access rules. Show only the information required for the task. Avoid copying sensitive records into a broad chat channel simply because that channel is convenient for alerts.

Also decide who can edit the routing rules themselves. A person who can approve an individual request may not be the right person to change the approval policy for all future requests. Keep those responsibilities separate where the work requires it, and make changes traceable. The exact controls depend on the system and the consequences of the action.

Run a handoff rehearsal

Use fictional records to test a complete request, a missing field, a rejected approval, an unanswered approval and a destination timeout. Ask the actual queue owner to handle them using the proposed interface. Watch whether they can identify the next action without a developer standing beside them. That is useful feedback about the design, not a test of their technical ability.

Include a shift change in the rehearsal. Another person should be able to open the queue, understand what has happened and continue within their authority. If they need a separate verbal explanation for every item, add the missing context to the record or simplify the workflow. A reliable handoff should survive an ordinary absence.

Review the reasons work returns to people

After a trial, look for recurring reasons that items need review. Some may indicate unclear input instructions or a category that should be added deliberately. Others may be judgments that should remain human. Do not measure success solely by reducing the number of reviews. A well-placed review can be the feature that makes the workflow usable.

Begin with one exception path. Write the stop reason, the owner, the evidence they need, the allowed decisions and the unanswered outcome. Then have a colleague walk through it using a fictional record. Once that handoff is clear, the ordinary automated path has a much firmer place to send the work it cannot responsibly finish.