Reassign, escalate or cancel workflow work¶

Use an intervention when responsibility must change or a workflow should end. Read the workflow and selected task first: transferring one task, recording a decision, returning a request and cancelling the whole workflow have different consequences.

This guide follows the intended WorkOS Final Screens. The frontend is still in progress. The inspected frontend detail is a preview built from example data; it does not establish these saved actions. Confirm connected availability with your administrator. This draft is not an environment or audience-acceptance record.

Choose the right action¶

Use the correct workspace and account. Interventions require permission beyond viewing a workflow. Being its requester, seeing its detail or having a managerial title does not itself establish that permission. Coordinate with the process owner and affected workers before changing responsibility or ending parallel work.

Reassign a task¶

1. Open Workflows → My work, or the relevant shared queue, then open the workflow. Follow the work-list guide if needed.
2. Read Overview and identify the exact task, current owner and linked project or case. If several tasks are active, confirm which one needs to move.
3. Open Task → Reassign when available.
4. In Assign to, choose the person who should take over. The inspected approval screen requires one named reviewer.
5. Add Position context (optional) when relevant, and a short Reason (optional) explaining the handoff. Position context accompanies the person; it cannot replace the reviewer selection.
6. Select Reassign task.
7. Refresh the saved task and verify its new owner, state and reason. Coordinate the handoff with that owner through your approved working process.

The task keeps its identity. Reassignment records a manual assignment, clears any previous claim record and sets the task to reassigned for a person or pending for a queue. It does not complete the task, approve the request, edit the request answers or automatically start a fresh deadline. Check the existing timing before promising the new owner a full new response window.

For approval work, the outstanding decision moves to the new named reviewer. A queue alone is not a valid replacement. Current design difference: one helper says that people, positions or pooled queues are available even though the same approval screen requires a named person and says a queue is unavailable. Follow the named-reviewer rule for that approval.

The backend has an ordinary-task queue reassignment path, but the inspected screen does not establish a complete general queue-target journey. Do not improvise a position-only or combined person-and-queue target. Ask an authorized process owner to use the supported connected flow for the task type. Do not use reassignment as an undocumented way to restart finished work.

Escalate to a person¶

1. Open the selected workflow's Task → Escalate action when available.
2. Choose the Escalation owner who should take responsibility for this task.
3. Add an Escalation reason when useful. Explain the issue and what the new owner needs to do; the current operation accepts an optional reason.
4. Select Escalate task.
5. Refresh the saved task and confirm the new named owner and escalation history. Check the existing due information and coordinate the intervention.

Manual escalation uses the reassignment behavior: it changes ownership and, for an approval, the pending reviewer. It does not calculate a management chain, select a route, complete work or merely add a second observer. Automatic service-level escalation is a separate policy-driven capability.

Current design difference: the escalation screen includes position-oriented helper text and an editable-looking Current assignment field. This operation saves the selected person and reason; it does not save a new position or queue. Do not rely on that extra field to preserve or change role context. The current assignment's position and queue context are cleared by this manual escalation path.

For work received from another organization, local assignment can also initiate a separate participation update. A saved reassignment or escalation is not confirmation that the other system has received it or that every cross-organization access decision is complete.

Cancel the whole workflow¶

1. Open the workflow and read Overview, its active work and any linked project or case.
2. Confirm with the responsible process owner that the whole workflow should end. Consider everyone working on parallel tasks and any handoff or signing already in progress.
3. Open Task → Cancel workflow.
4. Add a Cancellation reason (optional) that will help later readers understand the decision.
5. Select Cancel workflow to submit the action. The adjacent Cancel control leaves the action; it is not the workflow-ending action.
6. Refresh the saved workflow and confirm its actual status. Review the affected tasks and any outstanding linked work with the responsible team.

Cancellation sets a still-active workflow to cancelled and cancels tasks that have not already completed, been cancelled or been skipped. This also includes returned tasks. It clears the current step and pending local handoff information and records cancellation history. Completed work remains part of the history; cancellation is not deletion or a reversal of past decisions.

If the workflow was already completed, rejected, closed or cancelled, the current cancellation operation returns without changing that outcome. A success message alone therefore does not prove that a previously completed workflow became cancelled. Always inspect the refreshed saved status.

External-work limit: the screen says pending handoff or signing work stops. The inspected implementation clears the workflow's local waiting information and cancels a linked signing operation that is still submitted locally. That is not proof that an already-dispatched action in another service stopped, or that a completed document signature or business result was undone. Ask the responsible team to reconcile that work before treating the whole business process as stopped.

These actions do not establish an undo, restore or restart procedure. Contact support and the process owner if the wrong workflow was cancelled; do not create replacement work or repeat an external action without an agreed recovery decision.

Understand the separate Return design¶

The general workflow Return screen describes selecting a return route, adding a required reason and sending the task along that route. The inspected general workflow contract does not establish that complete operation. It remains a design and engineering dependency.

Do not substitute request correction, completion or cancellation for that intended routed return. For a form-backed request that genuinely needs requester changes, use its documented correction and resubmission journey. For other work, ask the process owner which supported action is available.

Resolve an uncertain or unavailable intervention¶

Share only the relevant information through an authorized support channel. Managers should distinguish a handoff from work completion, and executives should treat escalation and cancellation as operational events rather than evidence of productivity, savings or successful downstream delivery.