Create a ticket

How to start a ticket from the New button, a board, the Inbox, email, or the API, which fields you can set, and where each role may start one.

Written for
user
Roles
owner, admin, member, project-manager, client-user, elevated-client-user, agent
Requires
Any workspace user or client user; the projects you may start tickets on depend on your role and memberships
Feature
tickets

A ticket is the one object in SAQ for support requests, project work, and billable time. Anyone with access to a workspace can start one: workspace users on the projects they belong to, client users on the projects their client is attached to, and everyone in the shared Inbox when no project fits yet. Tickets also arrive by email and through the API.

Before you start

You need to be logged in to the workspace. Where you can start a ticket depends on your role:

Role Where you can start a ticket
Owner, Admin Any project, or the Inbox
Member Projects you belong to (as Member or Project manager), or the Inbox
Elevated client user Projects you are elevated on, projects where your client is the billing or a collaborating client, or the Inbox
Regular client user Projects where your client is the billing or a collaborating client; otherwise the Inbox
Agent account (API token) Every project; the Inbox only with the Triage scope and no project restriction on the token

A ticket started without a project lands in the shared Inbox, where a workspace user routes it to a project later. Client users are told: "Without a project your request goes to the workspace Inbox; the team routes it."

Steps

  1. Select New in the top bar, press c anywhere in the app, or open New ticket from the Tickets list, a board, or a project page. The form is at /w/acme/tickets/new. A board or project page preselects its project.
  2. Choose a Project, or leave Inbox selected.
  3. Enter a Title.
  4. Fill in the other fields you need (see below).
  5. Select Create ticket. The new ticket opens at its own address, for example /w/acme/tickets/ACME-184.

Other ways a ticket comes into being:

  • From the Inbox: open Inbox, select a message, and select Route. You choose the project, kind, assignee, and billing client; the email becomes the ticket's first content. See Triage the Inbox.
  • By email: a message to the workspace mailbox that does not match an existing ticket becomes an Inbox ticket with the inbound kind and the default priority. See Connect a mailbox.
  • From another system: POST /api/w/{slug}/tickets with an API token that has the Write scope, or the MCP tool create_ticket. See the API reference and the MCP page.

Fields

Field Meaning Rules and default
Project Where the ticket lives; decides who sees it and who is billed Inbox by default. The list shows only projects you may start tickets on.
Title One line Required, 1–200 characters
Description Markdown text Optional, up to 50 000 characters
Kind The kind of work (Planning, Implementation, Bug, Support by default) For tickets started by client users, and for Inbox tickets, the default is the workspace's inbound kind (Support). Otherwise the first kind in the workflow.
Priority Workspace priority Shown only to workspace users, and to client users elevated on the chosen project. Defaults to the workspace default priority (Medium).
Assignee One person Workspace users only, and only once a project is chosen. Unassigned by default.
Due Due date Same visibility as Priority. Empty by default.
Estimate Planned effort Workspace users only. "Leaf tickets only. Write 1h30, 90, or 45m." A plain number is minutes.

Start date, labels, and a parent ticket are set on the ticket page after creation. The API accepts them at creation time (startDate, labelIds, parentId), together with stateId and billingClientId.

Every new ticket starts in the workflow's reopen-target state (Backlog by default).

Rules

  • Ticket id. Each ticket gets an id such as ACME-184: the workspace's ticket prefix and a workspace-wide number that is never reused. If an Owner changes the prefix later, old ids keep resolving.
  • Reporter is a viewer. The person who creates the ticket is its reporter and always a viewer. The reporter can never be removed from the viewer list.
  • Regular client users get the defaults. If a regular client user sends a kind, state, priority, dates, labels, or an estimate (for example through the API), those values are ignored and the workspace defaults apply. Client users never choose the billing client.
  • Billing client. A ticket on a project is billed to the project's billing client by default. When a client user starts a ticket on a project where their client is the billing client or a collaborating client, the ticket is billed to their client. Inbox tickets have no billing client until they are routed. Workspace users see the hint "Billed to Acme by default; staff can change this on the ticket."
  • Notifications. A new Inbox ticket is emailed to workspace users whose notification preference is "Everything I can see". An assignee set at creation is emailed.

Examples

A support engineer at your company gets a phone call and creates a ticket on the customer's project with kind Support, priority High, and an assignee. The customer's client users see it immediately because it is billed to their client.

A client user logs in, selects New, leaves Inbox as the project, and describes the request. The team sees it in the Inbox and routes it to the right project.

Common problems

  • "You cannot start tickets here." You tried to start an Inbox ticket without the right to do so, typically with an API token that lacks the Triage scope or is limited to specific projects. Choose a project instead.
  • "You cannot start tickets on this project." You are not a member of the project, and your client is not attached to it. Ask a project manager, or start the ticket in the Inbox.
  • "The title is empty or too long." The title must be 1–200 characters.
  • "Write the estimate as 1h30, 90, or 45m." The estimate text could not be read as minutes.
  • "Only workspace users and elevated client users on the project can be assigned." The chosen assignee cannot hold the assignee field on this ticket.
  • Update a ticket Edit a ticket's title, description, kind, priority, labels, dates, estimate, and assignee from the ticket page, and who may change each field.
  • Find tickets Use the Tickets list, its filters, search, the command palette, and keyboard shortcuts to find any ticket you may see.
  • Share a ticket with viewers Give one person access to one ticket by adding them as a viewer or mentioning them, who may share with whom, and what a viewer can and cannot do.
  • 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.
  • 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.
  • Kind A kind says what type of work a ticket is; the workspace defines its kinds, names an inbound kind for email and client tickets, and bills by kind.
  • Priority A priority ranks tickets on the board; the workspace orders its priorities from lowest to highest and names one as the default for new tickets.
  • Estimate An estimate is the planned effort on a leaf ticket in minutes; a parent ticket shows the sum of the children the viewer may see.
  • 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.
  • Connect an MCP client The MCP endpoint, how Claude Code and Cursor are configured, every tool with its arguments and result, error shapes, rate limits, and the context pack.