Move a ticket

Move a ticket to another project or route it out of the Inbox, and what happens to its billing client, viewers, conversation, links, and logged time.

Written for
user
Roles
owner, admin, member, project-manager
Requires
Member of both projects; Owner or Admin for any move; any workspace user to route an Inbox ticket; Owner or Admin to confirm a billing-client reset
Feature
tickets

A ticket belongs to one project, or to the shared Inbox while nobody has routed it yet. Moving changes the project and therefore who sees the ticket and who is billed for its time. Routing is the special case of moving an Inbox ticket into its first project.

Before you start

Situation Who may do it
Route an Inbox ticket to any project Any workspace user (with an API token: the Triage scope)
Move between two projects, billing client unchanged Owner or Admin; or a Member who belongs to both projects
Move that resets the billing client Owner or Admin only, with explicit confirmation

Client users cannot move or route tickets.

Steps

  1. Open the ticket. In the Details rail, the Project row shows the current project (or Inbox).
  2. Select Move… (or Route to project… on an Inbox ticket).
  3. Choose the target Project. Owners and Admins see every other project; Members see the projects they belong to.
  4. On an Inbox ticket, choose the Billing client: Internal work (no client), the project's billing client (preselected), or one of its collaborating clients.
  5. On a project ticket, read the consequence line. Either "The billing client stays Acme." or "This move resets the billing client to Beta. Nothing is reset silently." In the second case an Owner or Admin must tick I confirm that Beta will see this thread.
  6. Select Move… or Route to project… to confirm.

An Inbox ticket that came in by email can also be routed from the Inbox page: select the message, choose a project, kind, assignee, and billing client, and select Route. See Triage the Inbox.

Rules

  • Billing client: keeps or resets. A move keeps the billing client when the target project bills that client or lists it as a collaborating client, or when the ticket is internal work and the target is an internal project. Otherwise the ticket takes the target's billing client, which changes who at the client can see the thread. Only an Owner or Admin may confirm such a reset; a Member is refused with "This move would reset the billing client. Only an owner or admin can confirm it."
  • Routing sets the billing client explicitly. An Inbox ticket has no billing client; routing assigns one, defaulting to the target project's. Nothing is reset silently.
  • What travels with the ticket. The id, the whole conversation at every audience, attachments, viewers, labels, links, GitHub links, and the time entries logged on it. Viewer grants keep working after the move, which is why every share is confirmed.
  • What does not change automatically: time attribution. Time entries keep the billing client they were logged under. After a move that changed the billing client, an Owner or Admin can select Re-attribute unbilled time in the Time group of the ticket page and confirm "Update unbilled entries to this ticket's current billing client? Entries with corrections and billed entries are excluded. This action is audited." Billed entries and entries with corrections are never touched. The pre-close checklist lists such tickets under "Moved or re-attributed tickets"; see Close a period.
  • Timeline. A move records "moved the ticket to Beta"; routing records "routed the ticket to Beta". A confirmed reset adds the Staff-only event "confirmed that the new billing client sees this thread"; routing records the billing client set.
  • Losing sight. A workspace user may route an Inbox ticket into a project they do not belong to. The move succeeds and the page then shows "Moved. You no longer have access to this ticket." This only happens when routing: a Member moves between projects they belong to, and Owners and Admins see every project.
  • Email. When an Inbox ticket created from an email is routed, the message leaves the mail Inbox.
  • API and MCP. POST /api/w/{slug}/tickets/{ref}/move takes projectId, and for routing optionally billingClientId, kindId, and assigneeId; a reset needs confirmReset: true. The MCP tool move_ticket accepts project keys and people by name or email. See the API reference.

Examples

Support routes a customer email: on the Inbox ticket, Route to project…, choose "Acme support", keep Billing client = Acme, confirm. The customer's client users now see the ticket.

A ticket landed on the wrong internal project: a Member of both projects selects Move…, sees "The billing client stays Internal work (no client).", and confirms.

A ticket billed to Acme must move to a project that bills Beta: an Admin selects Move…, reads "This move resets the billing client to Beta. Nothing is reset silently.", ticks the confirmation, and moves it. The Admin then decides whether to Re-attribute unbilled time.

Common problems

  • "You must be a full member of both projects to move this ticket." Ask an Owner or Admin, or a Member on both projects.
  • "This move would reset the billing client. Only an owner or admin can confirm it." The target project does not have the ticket's billing client; only an Owner or Admin can move it there.
  • "Confirm that the target project's billing client will see this thread." The confirmation box was not ticked.
  • "The billing client must be the project client or a collaborating client." While routing, you chose a client that is not attached to the target project.
  • "Moved. You no longer have access to this ticket." The move worked; you are not a member of the target project. Ask a project manager to add you if you need to follow it.
  • Triage the Inbox Route unmatched email and client-started tickets into a project, or merge a message into an existing ticket, from the shared Inbox.
  • Billing fields on a ticket What the Billing client, Policy, Mode, Billing description, and Estimate fields on a ticket mean, who may set them, and what changes when the billing client or kind changes.
  • Close a period Close a month or week so its time entries are frozen for billing, using the four-step wizard with its advisory checklist, first-period boundary, re-authentication, and typed confirmation.
  • Project A project is the collaboration boundary in a workspace, with its own key, members, billing client, collaborating clients, and billing mode.
  • Inbox and Review The Inbox is the shared queue of unrouted tickets and email; Review is the restricted queue for messages that belong to a narrower audience.
  • Tickets List, read, create, update, move, archive, delete, and redact tickets through the SAQ REST API, with every filter, body field, response field, and error.