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.

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

A kind is the type of work a ticket represents. A new workspace starts with four: Planning, Implementation, Bug, and Support. Owners and Admins add, rename, reorder, and archive kinds under Settings → Workflow and kinds. Kinds matter beyond sorting: billing policies are set per kind, so "Support is covered by the time bank, Implementation is paid" is expressed by kind.

How it relates to other concepts

  • The inbound kind (default Support) is given to tickets created from email and by client users. Workspace users choose a kind when they create a ticket.
  • A billing policy at workspace, client, or project level names a kind and a rule: paid, free, or a time bank.
  • Kinds are independent of states; every kind uses the same states and the same board.

Rules

  • A kind has a key (lowercase, fixed after creation) and a name of 1–60 characters, and a position in the pickers.
  • The inbound kind cannot be archived, and neither can the last remaining kind.
  • An archived kind disappears from the pickers; tickets that already have it keep it.
  • Changing a ticket's kind follows the ticket edit rules. An elevated client user's change of kind is refused while the ticket has unbilled billable time, because the kind can change how that time is billed.
  • A regular client user cannot choose a kind; their tickets always get the inbound kind.

Example

Nordic Retail's contract includes 10 hours of support per month. Acme sets the client's policy for Support to the time bank and leaves Bug and Implementation paid. A Support ticket that turns out to be a paid change request is re-kinded to Implementation by the consultant before the month's billing run.