How moving works
Ticket ownership transfers
Ticket ownership transfers
The ticket is removed from the original workspace and added to the destination workspace with all its history intact.
Ticket mirrors update
Ticket mirrors update
The in the original workspace’s is updated with a “moved” indicator showing where the ticket was relocated. A new mirror is automatically created in the destination workspace’s triage channel.
Notifications sent
Notifications sent
All stakeholders (assignee, followers, requester) are notified of the workspace change with context about the new location.
Thread messages sync
Thread messages sync
Request thread mirrors, DM mirrors, and triage channel mirrors are all updated to reflect the workspace change.
What gets preserved
What gets preserved
The following information is preserved:
- Ticket history: All messages, comments, and activity
- Properties: Status, priority, tags, categories, custom fields
- Relationships: Linked tickets, parent/child relationships
- Attachments: Files and images attached to the ticket
- Time tracking: SLA timers and due dates
What changes
What changes
The following elements change:
- Ticket ID: The ticket receives a new ID based on the destination workspace’s channel prefix
- Assignee: May need to be reassigned if the original assignee is not a member of the destination workspace
- Channel: The ticket is assigned to the default channel in the destination workspace
- Followers: Followers who are not members of the destination workspace are removed
Move a ticket
Use cases
Escalations
Escalations
Move complex issues to specialized teams or leadership workspaces for higher-level attention.
Routing corrections
Routing corrections
Fix tickets that were created in the wrong workspace due to initial misrouting.
Departmental transfers
Departmental transfers
Transfer requests that span multiple departments, such as moving from IT to HR or between cross-functional teams.