ITSM

The add-on ITSM is for IT and service teams. It answers four questions: what is broken right now, why it keeps happening, what you are about to change and what is supported in the first place. Beside the requests sits a register of defects in your own products. The whole picture is managed from the ITSM console.

Why you need it

A request can be closed, but its cause cannot. When the same failure arrives for the third time, support puts out fires one by one while customers write “you went down again”. At the same time nobody knows which work is planned for the weekend, which server sits at which client or until what date it is supported at all. The knowledge lives in correspondence and in one engineer’s head.

ITSM turns this into four clear objects. An incident shows the outage and groups the requests it hit, problems hold the causes of repeat failures together with a ready workaround, changes are planned with a rollback plan and approvals, and the asset registry answers “what is supported and where”. You find all of this out in advance instead of during an outage.

What it does

• An incident wraps a request, it is not a second request. The request keeps its owner, its correspondence and its deadline; the incident adds the outage view: the team’s own severity (sev1 to sev4 — the requester never grades an outage), the forward-only ladder detected, investigating, mitigating, monitoring, resolved, postmortem with its timeline stamps, the incident commander, the affected companies, assets and service, and the status-page reference.
• A major incident groups many requests, and monitoring can report one. One explicit command links many standing live requests to one open incident: one open incident holds a request at a time, and every skip is named rather than forgotten. A monitoring system can also register an outage through its own API address, exactly once per source and external id — a redelivered event doubles nothing and answers with the standing incident.
• The clocks of the affected requests pause. The pause decision is data on the incident and is on by default. While the incident stands, linking a request pauses its SLA clocks, with the reason naming the incident journaled in the SLA accounting and on the request’s own office history. The pause holds even while the customer writes, and lifts only by the incident’s own exit — its resolution or the unlink. Resolving fans out: every unstamped link resolves exactly once with the stamp “resolved within incident {id}” and one notification to the request’s owner; a request resolved by another hand is journaled and walked past.
• A severe outage cannot close without a review. For severity one and two the product demands a postmortem — cause, timeline, actions and owners — before the resolve rung, refused by name while it is missing. The time-to-recovery report is derived from the stamps (detection to resolution, median beside mean, every count visible), not from anyone’s summary.
• Problems are the “why it recurs”. A problem is born with a required owner (a real person, checked — a problem without an owner is a formality) and a service word, and walks the ladder new, investigating, known_error, resolved, closed. The gates sit on the rungs: known_error demands the workaround and its standing record, resolved demands the root cause, and closing stands on a resolved row. Records are never deleted — the closed rung seals the history.
• The recurrence count is derived, not stored. Recurrence is read from the incident links. A fresh incident naming an open problem’s service word inside a 30-day window links itself, journaled on both families; an empty word, a stale window or an ambiguous match (two open problems sharing one word) links nothing, and the office picks by hand.
• A known error publishes into the knowledge base, and the workaround reaches the agent. Publishing is a separate explicit command: one public article per record, the symptom in the customer’s words, the workaround copied verbatim, and the problem’s owner becomes the article’s owner. Without the knowledge add-on the command refuses by name and the card says why nothing was published; with it, the article feeds the suggestion loop like any other. Every request an open problem swallows shows the standing workaround, so an agent answers the third occurrence of the same failure with the documented fix while the real repair waits. The problem report sorts open problems by recurrence first and age second, each row carrying the volume of requests it swallowed and its owner named.
• A change has a window and an owner. A change is its own object so that “why it broke” can always point at “what we changed”: born with a required owner and a required pair of windows (start and end — a change without a window is a wish), carrying the risk word beside the impact, the rollback and test plans, the linked problems and incidents, and the affected companies and assets.
• The type is the route, fixed at submit. A standard change is pre-approved by its type and walks no chain. A normal or an emergency change submits together with its approval chain — one or two steps, each a named approver with its own timeout, walking in order (step two’s clock arms when step one decides) — and reaches approved through the chain’s decisions alone, never the office’s own command. An emergency change pays for the acceleration with a mandatory review at close. Submitting a normal or an emergency change demands the rollback plan.
• A silent approver cannot stall the work. Every decision is an immutable journal row — a rejection demands a comment and no edit path exists at all. An hourly sweep expires an unanswered step past its armed moment plus its timeout, escalates with one keyed ping to the seated approver and one to the change’s owner, and journals it. Expiry is a mark, never a verdict: the step stays decidable and the change advances on nothing.
• Closing demands a result, and the calendar keeps the plan. Closing a change demands the result text and the verification flag — an emergency additionally the review body — because “it worked” is a claim and the result says what was actually done. “Rolled back” is the other honest terminal, available only from implementing or verifying and with its own demanded note, and it is counted beside the closures by the emergency-ratio report, where an 80% share prints the warning that emergency became the norm. The change calendar derives on read over the windows, and the affected companies get one letter about the planned work per change, with addressless ones skipped by name.
• The asset registry and the criticality law. The registry answers one question honestly — which server, at which client, touched by which incidents — without pretending to be a full configuration management database. The kinds are server, workstation, network, mobile, software, license, service and cloud_resource; a row carries its identity seats (inventory number, serial, external id) under the dedup law — the same physical object cannot enter twice, a colliding seat refuses by name and names the standing row, and empty seats never collide. An asset links to a company, a contact, a request, an incident, a change or a contract, one standing link per pair; a critical asset’s link to a request raises the working priority to urgent exactly once, with the attribution journaled, never lowered and never walked back on unlink. An asset with standing links never deletes — it is archived with a demanded reason — while a row with nothing standing goes together with its journal. Bulk entry walks the CSV import with a named match key and a dry run that answers the exact reconciliation while writing nothing.
• Defects: your own bugs under control. A defect has a product and component, the version found and the version fixed (seated by the release command alone), its own severity and priority, a required owner and a seat for an external tracker reference. Born from a request, it inherits the context but not the judgements: the steps copy the request’s words verbatim (bounded, the cut said aloud), attachments ride by reference so bytes are never duplicated, and the title defaults to the request’s subject — while the owner, severity and priority come from the ask alone, because ten normal requests from the biggest client outweigh one urgent. Links carry a direction (symptom or affected), the ladder walks new, triaged, in_progress, fixed, verified, released with wont_fix and duplicate as branch terminals, and the duplicate rung demands the survivor and moves the mass onto it. Releasing demands the fix’s version and stamps “fixed in version X” onto every linked request, but resolves only the requests the command names — releasing never silently closes a request, and closing a request never closes its defect. One letter about the fix goes out per defect, with the per-request opt-out honored and named, and the exposure report shows which defect touches the most clients.

How it relates to other add-ons

ITSM declares two required add-ons — service and knowledge — and will not install without them. Without Service there is nothing to wrap and nothing to link, because there are simply no requests; without the Knowledge Base a known error has nowhere to be published — the publish command refuses by name while everything else in the add-on keeps working. The add-on catalog will not let you enable ITSM until both are installed. With SLA the relationship is practical: a major incident pauses a request’s clocks, and SLA is what keeps those clocks, so with SLA absent there are no clocks to pause. Contracts, in turn, relies on ITSM: a contract’s coverage is set over assets from the registry.

Honest limits

• Similar requests are not grouped into an incident automatically, and customer-facing status pages and on-call rosters do not exist — named deferrals.
• Problems are not detected from incidents on their own: the key is the service word, and the link stays a person’s act.
• There is no standalone known-error database: a record lives with its problem and is published as one article into the knowledge base.
• Change advisory-board meetings, libraries of standard-change templates and automatic change creation from a deployment are not built; what ships is route types and an approval chain.
• There is no full configuration management database: CI classes, typed relations, service maps and automatic discovery are not made. The registry answers one question — what is supported and where.
• There is no two-way sync with an external bug tracker: only a seat for the external reference, because one source of truth beats two.
• A request’s priority is not raised automatically by the number of reports: the exposure report shows who is affected, and a person decides.

All add-ons → Add-ons catalogue

← CRM Agent documentation