> ## 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.

# Move tickets

> Move tickets between Ravenna workspaces to reassign ownership when a request belongs to a different team or your org structure changes.

Move tickets from one <Tooltip headline="Workspaces" tip="Separate environments for different teams or departments" cta="Learn about workspaces" href="/documentation/platform/workspaces/overview">workspace</Tooltip> to another when a request needs to be handled by a different team or when organizational structure changes require ticket reassignment.

## Mental model

Moving a ticket transfers it from one workspace to another. This is a full ownership transfer, not a copy or share. The ticket leaves the source workspace entirely and becomes part of the destination workspace.

Key distinction: moving vs sharing.

| Operation | What happens                                                                              | Use when                                                          |
| --------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| **Move**  | Ticket transfers to a new workspace. Gets a new ticket ID. Removed from source workspace. | The ticket belongs to a different team entirely                   |
| **Share** | Ticket remains in its original workspace but becomes visible in additional channels.      | Multiple teams need visibility but the owning team stays the same |

Moving is irreversible. Sharing is reversible (unshare).

***

## What transfers and what changes

**Preserved on move:**

* Full message history, comments, and activity log
* Status, priority, tags, categories, custom field values
* Parent/child ticket relationships
* File attachments
* SLA timers and due dates

**Changed on move:**

* **Ticket ID**: The ticket receives a new ID with the destination workspace's channel prefix.
* **Channel**: The ticket is assigned to the default channel in the destination workspace.
* **Assignee**: May need reassignment if the original assignee is not a member of the destination workspace.
* **Followers**: Followers who are not members of the destination workspace are removed.
* **Slack mirrors**: Original triage channel mirror is updated with a "moved" indicator. A new mirror is created in the destination workspace's triage channel. Request thread and DM mirrors are updated.

***

## When to move tickets

Common patterns:

* **Misrouted tickets**: A ticket was created in the wrong workspace. Move it to the correct one.
* **Escalation to specialized teams**: A general IT ticket needs to go to the security team's workspace.
* **Departmental handoff**: An HR onboarding ticket needs IT provisioning handled in the IT workspace.

Do not move tickets when:

* Multiple teams need to collaborate on the same ticket. Use sharing instead.
* The ticket just needs a different assignee within the same workspace. Change the assignee instead.
* The ticket needs to be in a different channel within the same workspace. Change the channel instead.

***

## Constraints and gotchas

* Moving is irreversible. There is no "undo move" or "move back" operation.
* The ticket gets a new ID in the destination workspace. Any external references to the old ID will need updating.
* Followers who are not members of the destination workspace lose access immediately.
* The ticket is assigned to the destination workspace's default channel. If specific channel routing is needed, it must be updated manually after the move.
* All stakeholders (assignee, followers, requester) receive notifications about the move.
* Moving a ticket does not move its child tickets. Child tickets remain in their original workspace but maintain the parent-child relationship across workspaces.