Two switches turn on incidents, problems, changes, a services catalogue and approvals. Everything stays a ticket — one key format, one list, one query language, one permission model. And both switches default to off.
ITSM tooling accumulates objects. This one is defined as much by what it refuses to model.
A team that only wants issue tracking never sees a change record in their life.
ITIL can only be on while ITSM is on. That ordering is enforced, not documented — change control without incident and problem management is an audit artefact rather than a practice.
The framework in effect for a given piece of work resolves project column → organisation default → ITSM, so a single project can run ITIL inside an organisation that has not standardised on it, and a new project inherits whatever the organisation chose without anyone re-picking.
A service management project is its own world, the same way the Support Desk is: enforced by a ticket scope so SERVICE, HELPDESK and STANDARD tickets never leak into each other's lists, searches or dashboard widgets.
The single decision that everything else on this page follows from.
Service requests, incidents, problems and changes are all tickets carrying a requestKind: SERVICE_REQUEST, INCIDENT, PROBLEM or CHANGE.
There is no separate record type, no separate key format, no separate list and no separate permission model. A change is OPS-4417, the same way everything else is.
A single extension table holds requestedFor (raise on behalf of someone else), the request-type template id and name, the problem fields and the change fields.
Which is why turning ITIL off does not strand data, and turning it on does not migrate anything.
Because a change is a ticket, it appears on boards, on the roadmap, in the calendar, in reports, in automation rule selection and in dashboard widgets — with no ITSM-specific view to build or license.
And it is queryable: requestKind = CHANGE AND statusCategory != DONE is an ordinary TQL clause, not a report.
Requesters in a service management project have accounts, so "Raise a request" is a view of request types that opens the ordinary create dialog pre-filled.
Requesters without accounts belong in a Support Desk project with its passwordless customer portal. Two different populations, two different doors, no compromise in the middle.
Added by the extension table. Everything else is the ordinary ticket you already know.
requestedForSTANDARD · NORMAL · EMERGENCYLOW · MEDIUM · HIGHSUCCESSFUL · SUCCESSFUL_WITH_ISSUES · FAILED · ROLLED_BACK — the honest four, including the one everybody omits.The loop that stops your desk answering the same question all quarter.
Because all four kinds are tickets, the whole chain is one TQL query away: requestKind = PROBLEM AND service = "Payments" AND statusCategory != DONE.
The CMDB is where ITSM projects go to die. This is the part of it that pays for itself.
Tickets link to services many-to-many, and services are a first-class query field: service = "Payments", with negation reaching tickets that have no service at all — which is how you find the work nobody has mapped yet.
Retire rather than delete. Once tickets name a service, deleting it is refused with the count of tickets that would lose their history. Set it inactive instead: the historical record stays true, and nobody can raise new work against it.
What is deliberately absent is the dependency graph — no configuration items, no relationship types, no impact traversal. Maintaining that graph is a permanent second job, and the version that is 40% stale is worse than a flat list everybody trusts.
Enforced in the workflow, so a change cannot be implemented by someone clicking past it.
An approval is one named approver, one decision: status PENDING, APPROVED or REJECTED, with a comment, the requester, and timestamps. You can request approval from a list of approvers, decide, and withdraw a request. There is a fully-approved check on the ticket.
The workflow's requireApproval condition is what makes it real. Trakr's workflow conditions evaluate to a reason rather than a boolean, so a refused transition tells the user why:
A rejected approval blocks exactly as a pending one does: rejection is an answer, not an absence, and a change should not be able to escape it by waiting.
There is no CAB object, no quorum and no approval stages. A review board is modelled as an approval asked of several people — each answering once, each visible on the ticket, each blocking the transition until they have.
The reason is that staged approval workflows encode an org chart into a tool, and org charts change more often than tooling does. A list of named approvers is edited in seconds; a three-stage approval scheme is a migration.
A request type is not a new object. It is a ticket template that knows when to apply itself.
Ticket templates exist at three scopes — personal, project and organisation — and can carry an auto-apply binding to a ticket type and/or a request kind. "Raise a request" lists the templates bound in this project; picking one opens the ordinary create dialog, pre-filled.
Change the ticket type mid-create and the template clears its own skeleton rather than leaving fragments of the previous form behind. Configuration bundles carry the binding by name, so a template whose binding cannot be resolved on the target system still imports — the binding is dropped, the template is not.
The consequence worth stating: a request type cannot silently rewrite a ticket that arrived by email, by API, from the portal or from an automation rule. Only a human, in a dialog, gets pre-filled.
No. There are two organisation switches and both default to off. ITSM adds the service management project type, its section, problems, known errors and the services list. ITIL adds change control and per-ticket approvals on top, and can only be enabled while ITSM is on.
A team that only wants issue tracking never sees any of it. The framework in effect resolves project column → organisation default → ITSM, so one project can run ITIL inside an organisation that has not standardised on it.
No — everything is a ticket. Service requests, incidents, problems and changes are ordinary tickets carrying a requestKind of SERVICE_REQUEST, INCIDENT, PROBLEM or CHANGE. There is no separate record type, key format, list or permission model.
One extension table holds the ITIL-specific fields, so requestKind = PROBLEM is a normal TQL clause and a change appears on the same board, roadmap, calendar and report as everything else.
Raising a problem from an incident creates the problem in the same project and links both tickets two ways. A problem carries root cause, workaround and a known-error flag — a known error is simply a problem that has a workaround.
Open incidents linked to a known error say so, which is the whole point: the person triaging the twelfth report of the same fault sees the workaround without going looking for it.
No, and deliberately. An approval is one named approver answering once: pending, approved or rejected, with a comment, a requester and timestamps. You can request approval from a list of people, decide, and withdraw.
The workflow's requireApproval condition refuses the transition while anything is outstanding — pending or rejected both block — while a ticket nobody was asked about passes. A review board is an approval asked of several people. There is no CAB object, no quorum and no stages.
There is a services catalogue, and it is deliberately a flat list rather than a configuration-item graph: name, description, owner, criticality of LOW, MEDIUM, HIGH or CRITICAL, an active flag, scoped to the organisation or a project.
Tickets link to services many-to-many and TQL supports service = "Payments", with negation reaching tickets that have no service at all. A service in use is retired rather than deleted — deletion is refused with the count of tickets that name it.
Requesters who have accounts use "Raise a request", a view listing request types — ticket templates carrying a binding to a ticket type and/or request kind. Picking one opens the ordinary create dialog, pre-filled.
Requesters without accounts belong in a Support Desk project with its customer portal instead. Pre-fill happens in the create dialog only, never through the API, MCP or automation, and never overwrites text you have already typed.
Two switches, both off by default, on a tracker your engineers already use. Self-hostable, made in Belgium.