The ticket lifecycle and statuses

Every ticket carries a status that drives its place in the queue, SLA tracking, and timestamps.

How statuses work

Statuses are not hard-coded — they live in an admin-managed registry (/admin/ticket-statuses). Each status declares an SLA behaviour of active, paused, or resolved, which controls what the system does when a ticket enters it.

The open queue

A ticket is treated as open while its status is one of:

• open
• in_progress
• waiting_customer
• waiting_third_party
• reopened

New tickets start at open.

Side effects of a status change

When the status changes, the engine automatically:

• Pauses or resumes the SLA based on the status's behaviour, extending due dates by the paused minutes when work resumes.
• Stamps resolved_at when entering a resolved-behaviour status and clears it if the ticket is un-resolved.
• Stamps closed_at when the status becomes closed.
• Clears the "needs my reply" flag for waiting statuses such as waiting_customer, scheduled, and on_hold.
• Adds a system reply to the timeline, fires a workflow event, notifies watchers, and requests CSAT feedback on resolve/close.