ITSM: incidents, changes, problems

ITSM in Iskue is a set of work categories you switch on per project: service requests, incidents, problems, changes and post-incident reviews. Enabling a category seeds its ticket type, fields, workflow and create screen. ITSM tickets stay ordinary tickets — same workflow engine, TQL, boards, automation and permissions — with extra behaviour on top.

Incidents

• Priority matrix. Set Urgency and Impact and the priority follows from the project's matrix on create and edit, unless an agent ticks "Priority override".
• Timeline. Status changes, alerts, stakeholder updates and any comment containing #timeline write timeline entries, so the incident's story builds itself.
• Stakeholders. Users, contacts or plain email addresses receive stakeholder updates, separate from the working conversation.
• Alert intake. Monitoring tools post alerts to a per-project, secret-protected endpoint. A new alert opens an incident; repeats annotate the open one instead of duplicating it, and a resolved alert can resolve it.

Changes

A change carries a risk: rules (emergency change, high impact, overlap with a freeze, many services affected) raise it to a floor automatically. Change windows define freezes and maintenance periods, one-off or weekly in a timezone, shown on a change calendar. When the project blocks changes during freezes, the "Start implementing" transition is shut while a freeze overlaps, and your deployment pipeline can ask the same question through a change-gate endpoint with a personal access token. Changes go through an approval step with approver groups; a preset rule can auto-approve standard changes.

Problems and post-incident reviews

"Create problem" on an incident opens a problem that carries over the affected services and links back as the cause; a Known errors queue collects them. From a resolved incident, create a post-incident review (PIR) prefilled with the incident timeline, from an editable template.

Services and assets

A service has a tier (1–4), an owner (a user or a team), a status (active or deprecated) and relationships to other services (depends on, child of). Services are site-wide or belong to one project. Tickets name their affected services (affectedService in TQL). Assets-lite: an Assets project template holds one ticket per asset, a ticket-reference field links incidents and changes to them, each asset lists what references it, and TQL finds them with cf["Asset"] = KEY. Assets import from CSV.

Public status page

Each project can publish a public status page: every service shows operational, degraded or major outage, with a 30-day history bar. It exposes only service names, incident titles and stakeholder updates — never comments, never restricted tickets — and a page that is not enabled answers 404.

Playbooks

A playbook is an ordered set of steps — "Major incident", "Laptop onboarding" — that an agent runs on a ticket, or that starts by itself on a trigger. Each run is recorded on the ticket.

Products and entitlements

Define products and grant entitlements to a contact or a customer organization. The ticket panel shows the requester's entitlements, including their organization's, and TQL filters by them: entitlement = …, product = ….