Shared work between workspaces¶
Shared work brings work packages exchanged between connected workspaces into WorkOS. A package identifies the work, its sending or receiving workspace, the requested interaction, its exchange status and any primary-file information available. Use it to find an exchange and establish its context before deciding what to do next.
Availability: This draft covers sending and finding shared work, reading its detail and history, deciding whether to accept, reroute or reject it, adding colleagues, opening the primary document and filing received work into Records. The backend supports these operations with the limits described in each guide. The intended navigation follows inspected Final Screens; the inspected frontend still uses sample packages and unconnected controls. The guides also explain lifecycle evidence, background reporting and organization-data scope. The assistant explanation covers bounded answers, proposed changes, uncertain results and protected-file limits. Connected use, source refresh, environment delivery and reader acceptance remain unverified or unfinished.
Start with Find shared work for the intended steps, search limits and recovery. The guide explains why two readers may see different received work and why the Sent view is broader than a person's own submissions.
Continue with Read a shared-work package to understand routing, people with access, status, history and Records readiness. It explains why acceptance is different from completion and why the reader history is not a complete audit.
Use Accept, reroute or reject shared work for the intended confirmations, decision meanings and recovery after an uncertain response.
The decision-history explanation clarifies recorded rejection, occurrence time, generic actor attribution and why missing history is not permission to repeat a decision.
Use Add people to shared work to select colleagues, understand participation and recover from directory or submission problems.
Use Open the primary document for the intended viewer steps, session expiry and recovery. Its current implementation does not establish the design's download and print restrictions.
Use Add shared work to Records for the intended filing fields, receiving ownership, classification and retention, linked result and recovery after an uncertain submission.
Use Send work to a connected workspace for preparation, destination and ownership choices, review, upload interruptions and recovery after an uncertain send.
Use Understand shared-work progress and evidence to distinguish exchange status, recorded stages and outcomes, and understand corrections and partial-update recovery.
Use Understand shared-work updates and reporting for delayed or inconsistent views, notification meaning, retained participants and reporting reconciliation.
Use Shared work in organization data requests for the current export scope, broader deletion behavior and service-versus-platform completion.
What the list means¶
| View | What it helps you find | Important boundary |
|---|---|---|
| All | Received and sent work visible in the current workspace | This is not an unrestricted enterprise-wide register. |
| Received | Work received by the workspace that the signed-in person participates in | Another colleague may legitimately see a different set. |
| Sent | Work sent from the current workspace | The inspected read is not limited to packages sent personally by the reader. |
The work title and summary explain the package's subject. The other workspace tells you where it came from or where it went. The interaction describes what was requested. The status describes the recorded exchange state. These are separate facts: a request to act is not proof that the requested work has been completed.
The list's dates identify when work was requested or its exchange state last changed. They do not establish a due date, a delivery guarantee or the time that someone last opened a document. Missing primary-file details do not mean that the whole package is missing; read the package's context before drawing a conclusion.
Understand requested interactions¶
A package can request more than one kind of interaction. These explain the sender's intent; they do not prove that every corresponding action is currently available, authorized or complete.
| Requested interaction | Meaning for the receiving workspace |
|---|---|
| Action requested | The sender is asking the receiving workspace to act on the work. |
| View | The work is shared for review. Opening its file still requires an available protected viewing session. |
| Use as reference | The receiving workspace may need the shared work as context for its own process. |
| Import a copy | The sender requests a working copy in the receiving workspace; finding the package does not itself create that copy. |
| Submit back | The sender expects a completed submission to be returned. |
| Work together | The intended work involves contributions from both workspaces. |
| Complete on our behalf | The receiving workspace is asked to carry out the work for the sender. |
The current sending policy can allow fewer interactions than were requested. The sending guide explains this boundary. Use only the actions actually available for the package; the remaining lifecycle journeys still need reconciliation.
Access and responsibility¶
Open the correct workspace with your own signed-in account. Received-work visibility depends on recorded participation. Sent-work visibility uses the current workspace's outgoing records. Clearing a filter cannot extend either boundary, and a management title does not by itself establish additional access.
Being able to find a package does not establish authority to accept, reject, reroute, add people, file a record or open its document. In the intended journey, open the package and act only within your assigned responsibility. Decision controls and backend authority checks still need connected verification; a visible button alone is not proof of permission.
The workspace membership and permissions guide explains account and role administration. Enterprise administration explains the connected-workspace context. Those administrative arrangements and individual work decisions serve different purposes.
For managers and executives¶
Use the list to identify exchanges that need further examination and to coordinate with the responsible workspace. Always record which workspace, direction, search and status you used when comparing results. Received totals can differ between people because their participation differs; Sent totals are workspace scoped.
For example, a search returning three packages means that three records match that reader's current scope and filters. It does not establish three unanswered requests, three overdue items or three exchanges across the entire enterprise. The list is ordered by the most recent exchange-state change, not by urgency.
This browse response does not provide completion rates, financial savings, response-time targets, unread totals or a historical trend. Older frontend sample cards show additional metrics, but those samples are not a live business report. Open and assess the underlying work before making a workload or performance judgment.
Connections to other work¶
Shared work belongs to the exchange between workspaces. Records owns the governed record that may result from a separate filing action. A package appearing in the list is not proof that a record has been created. Likewise, a displayed file name is not a download permission or evidence that a protected viewing session can be opened.
Workspace and capability names can be obtained separately from the saved package information. If a name cannot be loaded, the work can still be listed. Confirm ambiguous context through an authorized channel before acting; a missing name does not prove that the connection or package was deleted.
Support and acceptance¶
When requesting help, provide the workspace, package title, approximate time, chosen filters and the visible error or missing information. Share confidential package content only through an approved support channel. Support should distinguish no matches, restricted visibility, an unavailable list and unavailable descriptive names.
The initial reader reviewer is the platform owner. Domain, technical and audience walkthroughs, connected application checks and full feature coverage remain open. This draft records the inspected reads, direct decision behavior and intended steps without claiming that the whole exchange lifecycle is complete.