> ## 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 workspace 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 * Priority * File attachments * SLA timers and due dates **Carried by name (matched or created in the destination workspace):** * **Status**: The destination status with the same label. Falls back to the destination's **Open** status if there is no match. * **Tags**: Matched by name; missing tags are created in the destination. * **Category**: Matched by name; created in the destination if it doesn't exist. * **Ticket attributes**: Matched by field key. Missing attribute fields are created in the destination. For `SELECT`/`MULTI_SELECT` fields, option values are matched by label; options with no equivalent in the destination are dropped. **Changed on move:** * **Ticket ID**: The ticket receives a new ID with the destination workspace's channel prefix. * **Channel**: The ticket moves to the destination channel you selected. * **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**: The 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. **Cleared on move:** * **Form**: Forms are workspace-scoped, so the association is dropped. Answers captured through the form stay in the ticket's history. * **Parent link**: Parent-child relationships cannot span workspaces, so moving a child detaches it from its parent, and moving a parent detaches all of its children. **After a cross-workspace move**, the ticket no longer appears in the source workspace's lists, counts, or sub-ticket views. If someone was on the ticket's detail page when it moved, they are redirected back to the ticket list. The exception is a ticket that is also shared into the workspace being viewed: it stays visible there through the share. *** ## 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, and the parent-child link does not survive a cross-workspace move. Moving a child detaches it from its parent; moving a parent detaches all of its children. If you need the family to stay together, move each ticket individually into the destination workspace and re-link them there. ## Related topics - [Triggers & actions](/documentation/automate/workflows/triggers-actions.md) - [Bulk move tickets](/api/ticket/bulk-move-tickets.md) - [Channels](/documentation/tickets/channels.md) - [Statuses](/documentation/tickets/organize/statuses.md) - [Merge tickets](/documentation/tickets/merge-tickets.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.