Ticket statuses

Every ticket has exactly one status. Statuses describe where the conversation stands and control what customers can do. Staff capabilities are governed by permissions, not by status.

The ten statuses

What staff can do, per status

Staff capabilities depend on permissions, not on the ticket status:

A few important nuances:

• Visibility is permission-based. Staff members without the View all tickets permission only see tickets they are assigned to, regardless of status.
• Staff can always message. There is no status that blocks staff replies; staff can post on a closed ticket, which is useful for follow-ups and audit notes.
• One closure schedule at a time. Staff can move a closure-scheduled ticket to any status, but scheduling another closure on it is rejected.

What customers can do, per status

The customer-side rules in one sentence each:

• Seeing a ticket: the ticket creator and active participants can see the ticket in any status, including closed.
• Replying and editing: blocked only on Closed. On every other status, including Resolved, customers can still reply and edit their own messages.
• Requesting closure: possible on any status except Closed, Pending closure, and Closure scheduled.
• Invite links: stop working as soon as the ticket is Resolved or Closed. On a closure-scheduled ticket they still work until the closure actually happens.

Automatic transitions

Some status changes happen without anyone clicking a status selector:

• Scheduled closure fires: when a ticket is Closure scheduled and the scheduled time passes, it is automatically closed and a system message is added.
• Scheduling a deletion closes the ticket: when staff schedules a ticket for deletion, the ticket is closed immediately (if not already closed); the deletion itself happens later at the scheduled time.
• Customer requests closure: the ticket moves to Pending closure immediately, and a satisfaction survey is created right away.
• Customer closes a scheduled ticket early: when a ticket is Closure scheduled, the customer can close it immediately instead of waiting.
• CSAT surveys follow the status: entering Resolved, Closed, Pending closure, or Closure scheduled creates a satisfaction survey; moving back out of these statuses deletes the survey if it has not been submitted yet. See CSAT surveys. Note that Awaiting release does not create a survey; the survey fires later, when the release moves the ticket to Resolved.
• GitHub events can move tickets: when GitHub auto-transition is enabled for the project, closing a linked issue as completed moves its tickets to Awaiting release, and publishing a release moves the repository's Awaiting release tickets to Resolved. Tickets already Resolved or Closed are never moved back. See GitHub integration.
• Automation workflows can move tickets: the Set status and Schedule closure actions change the status like a staff member would, with the same system message and the same survey rules.
• Favorites are cleared: entering Resolved or Closed removes the ticket from all customers' favorites.

A customer reply does not change the status, with one exception: when an automation scheduled the closure with Cancel if the customer replies checked, a reply from the customer cancels that closure and moves the ticket back to Open, with the system message "Scheduled closure cancelled: the customer replied". A closure scheduled by a staff member, or by a workflow without that option, is never cancelled by a reply. Otherwise, moving a ticket out of Awaiting customer after the customer answers is a manual staff action (or a workflow's).