> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Share tickets

> Share a Ravenna ticket into a channel in another workspace so both teams can work it, without moving the ticket or changing who owns it.

Share a ticket into a channel in another workspace when a second team needs to work the same request. The ticket keeps its home channel, its ID, and its owner. The other workspace gets full access to it, and you can take that access back at any time.

## Mental model

A share is a row in `SharedTicket`, one per (ticket, channel) pair, unique on that pair. It grants a channel visibility of a ticket it does not own. Nothing on the ticket itself changes: not `queueId`, not the number, not the prefix, not the assignee.

The UI's notion of "shared" is relative to where you are standing. `isTicketShared(ticket, currentWorkspace)` is true when the ticket's home workspace is not the workspace you are viewing from, which is why the action set differs by side:

| Viewing from                   | Actions offered          |
| ------------------------------ | ------------------------ |
| The ticket's home workspace    | **Share**, **Move**      |
| A workspace it was shared into | **Unshare**, no **Move** |

Key distinction: share vs move vs link.

| Operation | What happens                                                                                                                      | Use when                      |
| --------- | --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- |
| **Share** | A `SharedTicket` row makes the ticket visible in a channel in another workspace. Ownership, id, and prefix unchanged. Reversible. | Two teams work one request    |
| **Move**  | The ticket transfers to another channel or workspace and takes the destination's prefix. Irreversible.                            | The request belongs elsewhere |
| **Link**  | Two independent tickets reference each other.                                                                                     | Related but separate work     |

***

## Share mechanics

* The destination must be a channel in a workspace **other** than the one you are sharing from. The web picker enforces this by excluding the current workspace from its options; it filters the workspace list rather than validating after the fact.
* Sharing is idempotent. An existing `(ticketId, queueId)` share is returned as-is and no second event is dispatched.
* Validation, in order: the ticket must exist within the caller's organization, must not be archived (`ARCHIVED_TICKET_UPDATE`), and must not already live in the destination channel (`SAME_QUEUE_CONFLICT`).
* Permission is the standard ticket-mutation check. Callers at participant access level are rejected with `FORBIDDEN`; members and admins pass.
* A successful share dispatches a `SHARED` ticket event carrying the share id, the destination channel, and the home workspace. The timeline renders it as `shared the ticket with {workspace}`, naming the workspace rather than the channel.
* The workflow action resolves the destination workspace's bot user and shares as that user, so `authorId` on the event is the bot, not the person who published the workflow.

***

## Unshare mechanics

Unshare accepts either a channel or a workspace, and the two behave differently:

* Given a **channel**, it removes that one share.
* Given a **workspace** and no channel, it removes every share the ticket has into that workspace, one at a time. This is the path the home workspace's banner uses when you remove a workspace chip, which is why removing one chip can drop several channels.
* Each removal dispatches its own `UNSHARED` ticket event.
* Archived tickets are rejected the same way as on share.
* Unsharing your own workspace from a ticket you only hold through a share ends your access, so the web client redirects to the ticket list on success.

***

## Query behavior

Ticket queries for a workspace `OR` in `shares: { some: { queue: { workspaceId } } }`, so shared tickets appear in that workspace's lists, views, and searches by default. When the query is already scoped to a channel, the same channel id is applied to the share filter, so a share stays confined to the channel it was made to.

***

## API

`POST /tickets/share/{id}` where `id` is the ticket. Body:

```json theme={"system"}
{
  "data": { "queueId": "string (required, the destination channel)" }
}
```

`POST /tickets/unshare/{id}`. Body, at least one field:

```json theme={"system"}
{
  "data": {
    "queueId": "string (optional, remove this one share)",
    "workspaceId": "string (optional, remove every share into this workspace)"
  }
}
```

`POST /tickets/bulk-share` takes a list of ticket ids and one destination channel.

Unshare returns the ticket id and the channel ids it was unshared from. Authentication follows the standard REST conventions, see the [API overview](/api/overview).

All three routes are excluded from the MCP server, so no Copilot or MCP tool can share a ticket.

***

## Constraints and gotchas

* `queueId` in the API is a channel. The field keeps the legacy name.
* Sharing is organization-scoped. There is no cross-organization share.
* No read-only share exists. A destination workspace has the same write access as the home workspace.
* Bulk share does not mark channels a ticket already reaches, unlike the single-ticket picker, so a bulk operation can silently no-op for some of the selection.
* **Moving a ticket drops its shares into the destination workspace.** The move helper unshares every channel in the target workspace first, so the moved ticket does not carry a redundant "shared from" banner in the workspace that now owns it. Shares into other workspaces survive. Those removals do not dispatch `UNSHARED` events, so the timeline shows the move and not the implied unshares.
* Deleting a ticket cascades its shares.


## Related topics

- [Triggers & actions](/documentation/automate/workflows/triggers-actions.md)
- [Bulk share tickets](/api/ticket/bulk-share-tickets.md)
- [Move tickets](/documentation/tickets/move-tickets.md)
- [Channels](/documentation/tickets/channels.md)
- [Product Updates](/changelog/2026.md)