Merging, reopening and closing
Finishing a ticket, folding a duplicate into another, and getting one back when the customer returns.
Every ticket ends in one of five terminal states: solved, closed, spam,
merged or deleted. This page covers how it gets there and what can be undone.
Solving a ticket
Solve a ticket from the composer, with Send and set Solved, from the Status control in the ticket header, or in bulk from the Inbox.
Solving does more than change a field:
- it stamps the time the ticket was solved,
- and, the first time a ticket ever reaches
solved, it records a CSAT request on the timeline.
The CSAT request is recorded once per ticket. Solving, reopening and solving again does not ask the customer twice.
closed is the second finished state. Nothing in the product moves tickets from
solved to closed on a timer, so which of the two you use is your workflow's
choice.
A terminal ticket is frozen
Once a ticket is terminal it takes no new replies, no new internal notes, and no ordinary status change. The status control offers nothing, because the list of legal next statuses for a terminal ticket is empty.
Other fields stay editable. You can still retag, reassign or relink the customer on a solved ticket, which is what reporting cleanups need.
Reopening
Reopen appears in the ticket header on a solved or closed ticket. It is
the only way back.
Reopening does five things:
- sets the status to
open, - clears the solved time,
- clears the first-response stamp and any breach flag,
- restarts both SLA timers from now,
- and writes a reopen entry plus a status change on the timeline.
Because the first-response stamp is cleared, the next reply counts as a first response again and has a fresh target to hit. That is the intended behaviour: a reopened ticket is new work, and holding it to a target set days ago would not be honest.
Only solved and closed can be reopened. A spam or merged ticket cannot,
and the refusal says so.
Merging duplicates
Merging folds one ticket into another. The ticket you merge from is the one that goes away.
What happens:
- The source ticket moves to
mergedand records which ticket it went into. - Every event on the source is copied onto the winner, marked as having come from the merge, so the winner's timeline holds the whole story.
- A merge entry is written on both timelines.
Work continues on the winner.
Merging cannot be undone
The source ticket is terminal afterwards. It cannot be edited, and it cannot be reopened. There is no unmerge. Check which ticket you are merging away before you do it.
A ticket cannot be merged into itself, and both tickets must be in the same
workspace. A ticket that is already merged or spam cannot be merged again.
Merge is available through the API and not from a Studio screen today. The
operation is POST /v1/tickets/{ticket_id}/merge, where the ticket in the path
is the one that goes away and the body names the winner. See the
API reference.
Marking spam
spam is reachable from any live status. It is terminal and it cannot be
reopened, so it is the one status worth being sure about. It writes both a status
change and a spam entry on the timeline.
Closing several at once
The Inbox bulk toolbar can set a status across a selection. Tickets whose current status cannot legally reach the one you asked for are skipped rather than failing the whole action, and the result tells you which moved and which did not. Solving in bulk carries the same CSAT request as solving one at a time.