Ticket

The ticket is SAQ's one unit of work, with a human id like ACME-184, a kind, a state, a priority, a project, and the billing and time facts that follow it.

Written for
user, admin, integration-developer
Roles
Requires
Feature
tickets

A ticket is the one object everything in SAQ attaches to: a support request, a bug, a planned feature, a deliverable. It carries the conversation, the time logged against it, and the billing facts that decide what a client pays. There are no separate task, issue, or case objects, and no custom fields.

How it relates to other concepts

Rules

  • The id is the workspace prefix plus a number: ACME-184. Numbers are never reused. If the prefix changes, old ids keep theirs and still resolve.
  • Title 1–200 characters; description Markdown up to 50 000; billing description up to 500. Start and due dates are optional.
  • Defaults on creation: the reopen-target state, the workspace default priority, the project's billing client. Tickets started by a client user or by email get the inbound kind; Inbox tickets have no billing client until they are routed.
  • The reporter is always a viewer and cannot be removed.
  • The ticket records its source (the app, email, the API, or MCP) and who started it (a workspace user, a client user, or email).
  • closedAt is set when the state goes from open to closed and cleared when it reopens.
  • Archiving hides a ticket from lists, boards, and search unless the archived filter is on; it can be restored.
  • Deleting is an Owner or Admin action in the browser, refused while the ticket has billed time or time in a closed period; redact the content instead. Child tickets stay and lose their parent.

Example

ACME-184 arrives by email into the Inbox. A consultant routes it to retail-shop as a Bug, billed to Nordic Retail. She logs 45 minutes, writes the billing description "Fix checkout error on gift cards", and closes it in Done.