Ticket fields, time tracking and to-dos

Beyond the subject and the conversation, a ticket carries a set of structured fields. Some are built in and always present; others you define yourself.

The built-in fields

Every ticket has a subject and an optional description, the latter being the body of the original request. A ticket also carries a reference — a short human-readable identifier with a workspace-specific prefix, which is what you quote to a customer or to a colleague rather than an internal identifier.

Beyond those, a ticket has its status, priority and source; its assignee and team; the customer it belongs to; and its tags.

Tags are a plain list of labels with no separate tag catalogue behind them — you are not restricted to a predefined set, and a tag exists because a ticket has it. There is one behaviour to be careful about: editing tags replaces the whole list rather than adding to it. If you are working through the API and send a single tag, you have not added a tag, you have made it the only one. There is a cap on how many tags one ticket can carry.

The customer is the person the ticket is for. Note that there is no separate "requester" concept — the customer link is the one relationship of that kind, and attaching, changing or removing it is recorded on the timeline like any other change.

Custom fields

When the built-in fields do not capture what your team needs to record, define your own. A custom field definition has a key, a label, a type, and a position that controls where it appears.

The available field types are text, long text, number, date, select, multi-select, checkbox and URL. Select and multi-select carry their own list of options. A field can be marked required, and a field can be made inactive rather than deleted, which is how you retire a field without destroying the values already recorded against it.

Field keys are unique within a workspace. Values are stored per ticket, one per field, so a ticket only carries the fields that have actually been filled in.

Alongside custom fields there are ticket types, which let you classify tickets into categories of your own naming and assign a type to each ticket.

Editors can create and edit field definitions and ticket types; deleting either is an admin action, since removing a definition affects every ticket that ever used it.

Time tracking

Time is logged against a ticket in entries rather than as a running total. Each entry records who logged it, how many minutes, an optional description of what the time was spent on, and whether it is billable. Entries are not billable unless you say so.

A single entry must be at least one minute, and there is an upper bound of roughly thirty days on any one entry — a limit that exists to catch a mistyped figure rather than to constrain genuine work. If you need to record more than that, record it as several entries, which is more useful anyway because each can carry its own description.

Because entries carry a person and a billable flag, time can be summarised across tickets rather than only read one ticket at a time.

To-dos

A ticket can carry a checklist. Each to-do has a title and a done flag, and can additionally carry its own assignee and its own due date. To-dos have a position, so the list stays in the order you meant rather than the order things were typed.

To-dos are the right place for the sub-steps of a piece of work that is still one conversation with the customer: chase the supplier, confirm the address, issue the refund. Splitting such a ticket into three tickets would fragment the customer's thread; three to-dos keep the thread intact while still making the outstanding work visible.

Note that the per-to-do due date is the only due date you set by hand. A ticket's own deadlines — its first-response and resolution targets — are derived from the SLA policy that matches its priority, and are not directly editable.

Attachments

Tickets carry attachments, each recorded with its filename, content type and size.

Reshaping tickets

Four actions change the shape of a ticket rather than its contents.

Merging folds one ticket into another, which is what you do when the same customer wrote in twice about the same thing. The ticket that was merged is left in the merged state and points at its destination.

Splitting does the reverse: it takes messages off a ticket and starts a new ticket with them, for when one thread turns out to contain two unrelated problems. Only actual messages move — replies, internal notes and inbound messages from your channels — while the status changes and assignments stay behind with the original.

Snoozing sets a ticket aside until a chosen time. Snoozed tickets can be filtered for, so nothing disappears, and unsnoozing brings a ticket back by hand before its time is up.

Reopening brings a solved or closed ticket back to life, as described in the article on statuses.

All four are recorded on the timeline.