Module configuration
Tickets
The heart of service management — tickets, incidents, requests. Templates drive which questions appear, types link workflow and SLA, routing finds the right workgroup.
Updated May 18, 2026
Configuration · Modules · 4.9
The Tickets module is the engine behind every report — incidents, service requests, knowledge-base questions, change requests. Three objects work together here: the ticket type drives workflow and SLA, the ticket template decides which questions the submitter sees, and the routing delivers it to the right workgroup.
Why this matters to the business
"Tickets get stuck"
SLA per ticket type + escalation rules → nobody can "forget" them.
"Submitter forgets half of it"
Ticket template enforces required fields before the ticket is created.
"Wrong team gets it"
Routing rule on category/location/asset → automatic workgroup assignment.
"Statuses say nothing"
Workflow per ticket type → "In progress · Waiting on customer · Ready for review · Closed" — no vague "open".
The three configuration objects
Ticket type
Category of the ticket: Incident · Service Request · Change · Knowledge Question · Complaint. Drives workflow (see Building Blocks → Workflows) and SLA.
Ticket template
Which questions go to the submitter — examples: "Laptop broken" asks for the asset tag, "Meeting room issue" asks for the room. Reduces free text.
Routing rules
Condition → workgroup. "Category = IT hardware → workgroup IT-L1". Stackable with a fallback.
Standard fields on a ticket
| Field | What it's for |
|---|---|
| Title & description | The question or issue. AI uses these to make suggestions. |
| Submitter / requester | Who created the ticket. May differ from the end user (e.g. reception files on behalf). |
| Ticket type | Drives workflow and SLA. |
| Classification | Hierarchical categorisation (see Building Blocks → Classifications). |
| Priority | Impact × urgency (matrix) or set freely — agreed in 4.6. |
| Workgroup / handler | Who picks it up. Derived via routing or set explicitly. |
| Related CI / location | Which asset or room the ticket touches. |
| Status & SLA clock | Status from the workflow; SLA shows remaining time, pauses on "Waiting on customer". |
| Attachments & communication | Screenshots, photos, email threads — all on the same timeline. |
Which decisions will you make?
Which ticket types do you distinguish?
Keep it small — 3 to 6 types. Too many = nobody picks correctly.
Templates free or guided?
Template-first for specific flows (broken laptop, badge request). Free input for "other" with routing on classification.
Who sets priority?
Submitter (fast, prone to "everything is P1") or automatic via matrix (structured, requires training).
Can the end user close their own ticket?
Fine for service requests; for incidents usually the handler — that keeps a grip on resolution-time metrics.