Ticketing

The ticketing plugin is an ITIL-shaped ticket system that lives next to the catalogue, so a ticket knows which service it is about, who owns that service, and what the service's SLA promised. It is a licensed plugin.

Types

Keeping the four apart is the point: incident MTTR and request fulfilment time are different numbers and should not average into one.

Status

OPEN → IN_PROGRESS → RESOLVED → CLOSED, with ON_HOLD reachable from IN_PROGRESS and back. Which transitions exist, and which group may make them, is the ticket's workflow; see Ticketing configuration. RESOLVED can be reopened.

Priority is derived

A ticket carries impact (how many are affected) and urgency (how fast it hurts). Priority is read off the matrix:

Changing impact or urgency re-derives the priority. Setting the priority explicitly is an override, and stays one until impact or urgency change again. An incomplete pair derives MEDIUM, never a silent CRITICAL or LOW.

Deadlines

The priority drives the deadlines. This is the ITIL correction: a P1 and a routine query on the same service no longer share a clock.

Two more specific statements can apply on top:

• The catalogue item, when the ticket was raised from one. "Password reset in 30 minutes" is a deliberate promise for that kind of request and overrides the priority default.
• The service's own SLA definition, which may only tighten a target. A stricter contract wins; a low-criticality service can never slow a critical ticket down.

Deadlines run in the calendar the service's SLA definition names: 24×7 for the critical and high tiers, business hours for medium and low. A change of priority re-levels the deadlines of an open ticket.

On hold stops the clock. Moving a ticket to ON_HOLD pauses both deadlines; moving it back resumes them. Waiting on a customer is not the team's time. pauseTicketSLA and resumeTicketSLA do the same without changing status, for the cases that need it.

Fifteen minutes before a deadline every watcher is notified once; at the breach, once more. Breaches also fire the ticket:sla_breached WebSocket event and the TICKET_SLA_BREACHED notification.

Queues and assignment

A ticket has a group (the queue) and, optionally, an assignee. The workflow decides which group a ticket starts in and which group may move it; assigning it to a person keeps it in its group. Assignment, reassignment and every status change are in the ticket's history with who and when.

Operators and above can raise a ticket on somebody's behalf: createTicket takes a requesterId, and the requester sees the ticket as their own.

Automatic incidents

When a service with autoIncident: true goes DOWN:

1. the SLA plugin opens an incident with source MONITORING;
2. the ticketing plugin opens a ticket from the service's incidentCatalogItem (outage_report by default): type INCIDENT, impact and urgency from the service's criticality, priority derived, deadlines set, and the queue taken from the catalogue item's workflow;
3. the ticket carries the service's ownership block, so the on-call name is on it.

When the service recovers and nobody has touched the ticket, it resolves itself with a note saying the service came back and when. A ticket somebody has commented on, assigned or moved is left alone, because at that point a person owns it. The whole cycle takes under 30 seconds from the status change.

Everything else on a ticket

• Comments, editable and deletable by their author, with @mentions that notify.
• Worklog entries with time spent.
• Watchers, who receive every notification about the ticket.
• Relations between tickets (linkTickets), for a problem that groups incidents or a change that fixes one.
• Attachments: up to 10 MiB per file, uploaded with a user session (not the operator key) through POST /api/v1/tickets/{id}/attachments.
• Audit trail: status history, assignment history and field changes, all queryable.
• Saved filters per user, and a search that covers title, description and number.

Who can do what

The four platform roles apply. Requesters raise and follow their own tickets; operators work any ticket; admins delete and restore; viewers read everything and change nothing. Field-level permissions can hide or lock individual fields per group, for example making priority read-only for requesters. See Users, groups and roles.

Events

Every change is published on the WebSocket (ticket:created, ticket:updated, ticket:assigned, ticket:sla_breached and friends), as in-app notifications (TICKET_ASSIGNED, TICKET_COMMENTED, TICKET_STATUS_CHANGED, TICKET_RESOLVED, TICKET_DUE_SOON, TICKET_SLA_BREACHED, TICKET_MENTIONED) and as webhook events (ticket.created … ticket.deleted). Anything the UI would tell a person can therefore reach Slack, Teams or your own integration.

GraphQL entry points

Queries: ticket, tickets, ticketByNumber, myTickets, ticketComments, ticketStatusHistory, ticketWorklog, ticketWatchers, ticketRelations, ticketAttachments, availableWorkflows, availableCatalogCategories, availableCatalogItems, availableGroups. Mutations: createTicket, updateTicket, transitionTicket, assignTicket, resolveTicket, closeTicket, reopenTicket, deleteTicket, restoreTicket, addTicketComment, editTicketComment, deleteTicketComment, logTicketWork, deleteTicketWorklog, watchTicket, unwatchTicket, linkTickets, unlinkTickets, pauseTicketSLA, resumeTicketSLA, deleteTicketAttachment.