The three types you start with cover most work, but a process that has its own shape usually deserves its own type — onboarding requests, security reviews, returns. Each type gets its own board, its own columns and its own fields.
Open the board settings from the inbox. You give the type a name, an icon and a menu name, and choose how it should be displayed: as an inbox, which reads like a mailbox, or as a board with columns for work that moves through stages.
Choose that deliberately. An inbox suits anything answered once; a board suits anything handed between people. Getting it wrong is the main reason a type feels awkward to work with.
Each type carries its own columns, and you name them for your process rather than accepting the defaults. The Open and Done columns are fixed, but the ones between them are yours — a returns board might run Received, Inspecting, Refunded and Rejected.
Custom fields capture what your process needs beyond the conversation — an order number, an affected environment, a severity. Each has a type, which decides what can be entered and how it behaves in filters and automations.
Prefer a constrained type over free text wherever the answer is known. A select field with four options can be filtered, counted, and routed on; the same thing as text gives you four spellings within a month.
A field can be shown when a ticket is created, in the ticket detail, or in the sidebar — and there are shared variants for fields that should appear on the detail or sidebar across types.
This is worth more thought than it sounds. A field on the creation form is one more thing between a customer and telling you their problem, so put it there only when you genuinely can't proceed without it. Everything else belongs in the sidebar, filled in by your team.
Fields accumulate. Each one is something to fill in, something that goes stale when nobody does, and something that makes the sidebar harder to read.
A good test before adding one: what decision does this change? A field that routes a ticket, sets a priority or answers a question your team would otherwise have to ask earns its place. One that exists so the data is there "in case we need it" usually ends up half-filled and untrustworthy.
