Work Management
Tickets
Configure ticket dashboards, categories, form schemas, attributes, pipelines, and service flows.
Tickets
Tickets covers The support and service management surface: dashboards, ticket list, categories, subcategories, schemas, pipelines, workflows, and ticket detail pages. Use this page when you are configuring the live product surface, planning a rollout, or checking why users see different data from what an administrator sees.
What this surface is
- Primary purpose: The support and service management surface: dashboards, ticket list, categories, subcategories, schemas, pipelines, workflows, and ticket detail pages.
- Where staff start: Staff work from
/tickets/dashboard,/tickets/my-dashboard,/tickets/list, and/tickets/open-a-ticket. - Where admins configure it: Admins configure categories at
/tickets/settings/categories, subcategories at/tickets/settings/sub-categories, pipelines at/tickets/settings/pipelines, and ticket workflows at/tickets/settings/workflow. - Runtime/detail surface: Ticket detail pages use
/tickets/ticket/:ticketId/viewand include overview, timeline, actions, related tasks, and additional information. - Platform connections: Tickets connect to Omnichannel, customer portal, tasks, approvals, workflows, reports, and notifications.
Common workflows
| Workflow | What happens | Where to check |
|---|---|---|
| Map incoming | Map incoming request types into categories and subcategories before creating forms | Confirm in the product route above before publishing. |
| Configure form | Configure form schema for each category and subcategory so agents capture the right diagnostic fields | Confirm in the product route above before publishing. |
| Set up | Set up pipelines and stages for queues that need lifecycle tracking beyond open and closed | Confirm in the product route above before publishing. |
| Create ticket | Create ticket workflows where category-specific automation should assign, notify, approve, or escalate | Confirm in the product route above before publishing. |
Configure it
- Map incoming request types into categories and subcategories before creating forms.
- Configure form schema for each category and subcategory so agents capture the right diagnostic fields.
- Set up pipelines and stages for queues that need lifecycle tracking beyond open and closed.
- Create ticket workflows where category-specific automation should assign, notify, approve, or escalate.
- Configure dashboards and lists around team queues, priorities, SLAs, or ownership.
- Test ticket creation from staff, customer portal, public intake, and channels that create tickets.
- Check notification templates for assignment, replies, status updates, and closure.
- Run a sample ticket through the full lifecycle and verify reports, comments, and related tasks.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Dashboard | Agents need workload and activity overview | Route: /tickets/dashboard. |
| My dashboard | Agents need their own queue | Route: /tickets/my-dashboard. |
| List | Managers need filtered review | Route: /tickets/list. |
| Category schema | Different ticket types need different fields | Route: /tickets/settings/categories/:categoryId/:subCategoryId/schema. |
| Pipeline | Tickets need stages and transitions | Route: /tickets/settings/pipelines/:pipelineId/stages. |
| Workflow | Category-specific process should run | Route: /tickets/settings/workflow/:templateGroupId/:templateId/studio. |
Operating notes
- Keep category names customer-readable when tickets can be opened from the portal.
- Use subcategories for routing and schema differences, not for every minor issue label.
- Pipelines should represent operational state; tags or fields are better for classification.
- If a ticket is missing from a dashboard, check assignment, team, category filter, and stage filter.
- Omnichannel messages should preserve the conversation thread when possible.
- Agents need permission to view related customer, object, and task records.
- Do not close tickets automatically unless the workflow also records why and notifies the requester.
- Use ticket workflows for repeatable service processes and tasks for follow-up work.
- Review stale open tickets by category to find missing assignment or escalation rules.
- Test customer-visible status names so internal stage names do not leak confusing language.
For developers
Use the developer and reference pages when this configuration is read or changed by code, scripts, widgets, embeds, API clients, or webhooks.
- /developer/overview
- /developer/quickstart-api
- /reference/jql-overview
- /reference/namespaces
- /developer/inbound-webhooks
- /developer/realtime-streams