The plugins
Layers
The desk is built in layers. Cases are always there: the inbox, replies, accounts and contacts, forms and portals, service levels, automations, surveys and reports. On its own that is a support desk, for any team that answers customers. Plugins add to it, and some are built on others:
- Cases
- Service Configuration: the services you deliver, for IT service desks.
- Incident Management
- Major Incident Management
- Status Page
- Problem Management (also needs Incident Management)
- Change Management
- Incident Management
- Software Development
- Access Management
- Service Configuration: the services you deliver, for IT service desks.
Software Development and Access Management need nothing but the desk, so a support desk can use them without the IT plugins. The setup wizard asks what you are setting up and turns the plugins for it on; you change it here later.
This desk comes with these plugins:
| Plugin | Built on | What it adds |
|---|---|---|
| Service Configuration | Cases | The services you deliver, for IT service desks |
| Software Development | Cases | Projects with boards of developer tasks |
| Incident Management | Service Configuration | Incidents, their priority, targets and updates |
| Major Incident Management | Incident Management | Major incidents, escalation and reviews |
| Status Page | Incident Management | A public status page on the support portals |
| Problem Management | Service Configuration and Incident Management | The causes behind incidents, and known errors |
| Change Management | Service Configuration | Changes to services, judged for risk and approved |
| Access Management | Cases | Who got access to what, and access reviews |
Service Configuration
The services you deliver, in the service catalogue: their owners, support teams, offerings, dependencies, health, suppliers and reviews, and each service's history. Incident, Problem and Change Management are built on it; Major Incident Management and Status Page are built on Incident Management. In the sidebar it has Services, Suppliers and Reviews.
Its page in Settings:
| Tab | What it sets |
|---|---|
| Forms | Which service types contacts can pick in a form's Service field: business services only, until you add technical ones. |
| Audit | Audit scopes and how often records are reviewed. |
Turn it off to make the desk a plain support desk again, without losing anything the IT plugins hold.
Software Development
Projects with kanban boards of developer tasks, linked to cases. Access to a project comes from the business units connected to it and the people added by name, with project roles (owner, member, viewer). Projects have sprints, epics and subtasks, and fields of a project's own. See Software Development.
Its page in Settings lists every project, with its owners.
Incident Management
Built on Service Configuration. Incidents are declared from cases or on the Incidents page. Each has a priority (P1–P4) from impact and urgency, response and resolve targets, a status from New to Closed with On hold, resolution codes, a commander, a timeline and linked cases. You send updates to every requester at once, and write a review afterwards. See incidents.
Its page in Settings, per organization:
| Tab | What it sets |
|---|---|
| Lifecycle | Days before resolved incidents close (default 3); the reminder and the automatic resolve for incidents waiting on the customer (3 and 4 days); whether resolving needs a code and a note, and the codes; whether cases can be linked to resolved and closed incidents (on). |
| Priority and targets | The impact × urgency matrix, and how soon each priority must be taken and resolved, around the clock or in business hours (a calendar from Settings → Service levels). |
| Categories | Categories with subcategories, for filters and reports. |
| Notifications | The priorities that email the affected units' agents (P1 and P2), and extra people who hear about those, missed targets and long waits. |
Major Incident Management
Built on Incident Management. Major incidents have a manager, communications lead and technical lead, and a procedure checklist. They escalate when nobody takes them or updates stop, send stakeholder updates on a rhythm, and need a post-incident review with owners, due dates and actions (which can become dev tasks). See major incidents.
Its page in Settings, per organization:
| Tab | What it sets |
|---|---|
| Declaring and reviews | Priorities that are major by themselves, priorities that need a review even when not major, days until a review is due, and the review template. |
| Procedure | The checklist new major incidents start with. |
| Escalation and stakeholders | When to escalate, the levels (people and units), the default stakeholders and how often an update is due. |
Status Page
Built on Incident Management. A public status page on the support portals with the incidents your team makes public, and email updates for the people who follow it. See status page.
Its page in Settings, per organization: Status pages, the portals that have one, with each page's address and how many people follow it.
Turned off, the pages are gone and incidents' updates go to the linked cases only. The subscribers and the incidents' public marks stay for when it is turned on again.
Problem Management
Built on Service Configuration and Incident Management. The causes behind incidents, known errors with workarounds agents see on cases, root cause sign-off, risk acceptances, and the fix through a change. See problems. In the sidebar it has Problems, Known errors and Problem reviews.
Its page in Settings: General (watch period, review dates, sign-off, suggestions on cases, investigation templates).
Change Management
Built on Service Configuration. Changes to services: planned, judged for risk, approved by policy (the service's owner, the CAB, the customers), carried out in their window and reviewed, with the evidence auditors test. See changes. In the sidebar it has Changes and CAB.
Its page in Settings, per organization:
| Tab | What it sets |
|---|---|
| General | Separation of duties, review deadline, customer approval, categories. |
| Risk | The questions and their points. |
| Approval policies | The approval policies. |
| History | Every change to these. |
Access Management
The history of who got and lost access to what, who can see something and why, and what a person can see and why. It runs access reviews with reviewers, reminders and CSV evidence, and alerts. The audit log becomes searchable and exportable, kept per kind of entry and sealed. See Access Management.
Its page in Settings: Alerts and retention.