Staging draft Work in progress · For review; coverage and acceptance incomplete

Find and take ownership of workflow work¶

My work brings together tasks assigned to you. Pooled queues hold shared work that a member can take responsibility for. Claiming a queue task records you as its owner; it does not complete the task, approve the request or change its answers.

This guide follows the intended WorkOS Final Screens. The frontend remains in progress: the inspected pages display sample work, and their Claim link navigates to a preview rather than proving a saved claim. Confirm connected availability with your workspace administrator. This is a documentation draft, not a production-readiness or audience-acceptance record.

Choose the appropriate work list¶

Destination	What to use it for
My work	Find tasks assigned to your signed-in account and open the relevant workflow. Several rows can belong to one workflow.
Pooled queues	Find shared queues that your current membership allows you to open, including queues with no pending work.
A selected queue	Review tasks still pending in that queue and select the work you intend to claim.
Requests	Start a request, follow your submitted requests or correct a returned request. See the request guide.
Document approvals	Follow the separate document-approval journey. Its presence beside My work does not make every workflow task a document approval.

Use the correct workspace and account. Access to view workflow work, membership of a queue and permission to claim work are separate requirements. Administrators maintain the staff, position and queue assignments that establish membership. A support role or a visible example page does not grant that authority.

Open work assigned to you¶

Open Workflows, then My work.
Identify the workflow title and the particular step you need to handle. Compare the task's status and creation time; two tasks on the same workflow can have different owners or outcomes.
Select Open workflow.
Read Overview for context and use Task for the selected work's available actions. Where linked work is available, confirm that it is the project, case or request you intended to open.
Follow the action appropriate to that task. Completion, approval, correction and reassignment have different consequences; use the request guide for request-related steps.

The personal inbox has backend paging. Its total describes matching task rows, not unique workflows, completed work or every task in your organization. The current read excludes completed, cancelled and skipped tasks; it can still include a returned task. A listed item is therefore not a guarantee that you can act on it now. Check its latest detail and available actions.

The final-screen summary cards show example counts. The inspected personal-list response does not supply all the timing and overdue facts shown by the design. Do not treat an example overdue badge, a page's row count or the oldest creation date as a verified service-level measure.

Find the shared queue¶

In Workflows, select Pooled queues.
Review the queue name, membership explanation and pending workload. Select the queue whose purpose fits the work you are authorized to perform.
Select Open queue.
In the selected queue, identify the workflow and step. Use Open workflow detail to read its context before claiming it.

The catalog uses current membership and active queues. Membership can arise from a direct staff assignment, a temporary user override or an eligible position occupancy. Changes to those assignments and their effective dates can change which queues appear. If a queue disappears, ask the administrator to check the current assignment; an old bookmark is not proof of continuing membership.

A queue can appear with zero pending tasks because membership and workload are different facts. If membership lookup fails, the service reports failure; that must not be presented as a successful empty catalog. An empty queue is not evidence that all of its former work was completed.

Interpret queue workload¶

Queue counts describe tasks still pending in the queue. Claimed work moves into the person's assigned workload and is no longer included in that pending list. The current queue detail is not a history of claimed or completed work.

The catalog can report pending work, warning-due work, work past its completion deadline, and the oldest/latest pending creation times. These do not measure the same thing. In particular, an overdue completion is different from a missed response target, and an old task is not automatically overdue. The catalog prioritizes queues with breaches, then warnings, then more pending work.

Current design differences: the catalog examples use task-like queue labels such as Assigned and In progress, and some counts disagree with the displayed rows. The selected-queue examples also show overdue information that its current list response does not carry. Use verified saved context when available; do not infer a missing deadline or claim that the catalog counts all work already in people's hands. These differences remain tracked for design and implementation reconciliation.

Claim one task¶

Open the appropriate queue and select the pending task.
Read Open workflow detail when you need the workflow's purpose or supporting context.
Choose Claim selected task, or open Task → Claim queue task in the intended detail journey.
Confirm that the selected task is the one you intend to own and that it is still available to you. Select Claim task.
Refresh the saved task and verify that you are its named owner. Check My work and the queue again before starting work.

A successful claim records the claiming person and time, assigns the task to that person, and records a workflow event. It also supplies the first-response time when one has not already been recorded. The task retains its queue identity for context. Claiming does not select the next workflow route or establish that an external notification was delivered.

Current design difference: the claim screen includes an available-route selector, an optional note and reopened form fields. The current claim operation does not save those inputs. Do not rely on that screen to submit a note, amend request answers or route work onward. Those actions need their own supported operation.

Claim only work you are authorized and ready to handle. If another person has already taken the task, refresh and coordinate with the owner. The inspected sequential guard rejects a task that is no longer pending; simultaneous-claim handling still needs environment verification. Do not assume that two near-simultaneous attempts are safely resolved just because an example page changes.

Bulk claiming, pausing a queue and automatically enforcing a per-person claim limit have not been established by these runtime operations. Controls for those ideas in a preview are not evidence that the changes will be saved.

Acknowledging assigned work¶

The backend also supports acknowledging receipt of an eligible assigned task. Acknowledgment records the first response and can mark assigned work accepted. It does not complete the task or make an approval decision.

This applies to an active ordinary task assigned to the current person and using the newer service-level configuration. It is not an approval-task action. A prior claim can already have recorded the first response, so a separate acknowledgment may no longer be offered. Repeating acknowledgment does not replace an existing first-response time.

The inspected Final Screens do not establish a complete acknowledgment journey. The design task remains open for its action, confirmation and recovery states; this guide does not invent a button location. Ask your administrator which connected actions are available in your environment.

Recover from an unavailable or uncertain action¶

Situation	Next step
A queue you expected is absent	Confirm the workspace/account, then ask an administrator to check the active queue, staff or position membership and effective dates.
Queue lookup reports failure	Retry the read when appropriate or contact support. Treat the workload as unknown until the read succeeds.
Queue opens with no pending work	Check My work for an earlier claim. Do not assume that the missing task completed.
Workflow opens but no claim action is available	Refresh the task and check its owner, current status and your access. Some general workflow contexts still need implementation work.
Claim is rejected because work changed	Read the latest owner and status; coordinate through the responsible team instead of repeatedly claiming it.
Claim or acknowledgment times out	Refresh the task and personal/queue lists before retrying. Preserve the task identity and time so support can reconcile saved state.
You claimed the wrong task	Ask the process owner about authorized reassignment. This flow does not establish a self-service unclaim action.
Work needs correction or a decision	Use the appropriate supported task action. A claim or acknowledgment cannot substitute for that action.

Give authorized support the workspace, workflow reference when available, task name, time and visible message. Share only necessary information. For an authorized change of owner or an end to the workflow, follow the manual intervention guide. Managers should check pending queue work and assigned work separately when allocating responsibility; neither list alone establishes capacity, productivity or contractual service performance.