Services

A service is something you deliver that people rely on and ask for help with: Email, the online store, the VPN, payroll. The service catalogue is your list of them: who owns each one, which team supports it, who uses it, and what it needs to work. Cases, incidents, problems and changes point at a service, so the desk can route work, tell the right people and show what is affected when something breaks.

Services come with the Service Configuration plugin: the services you deliver, with their owners, support teams, offerings, dependencies, health, suppliers and reviews. Incident, Problem and Change Management are built on it.

In the sidebar, under Plugins, it shows as Service Configuration with Services, Suppliers and Reviews under it. Problem reviews and the CAB are under Problem and Change Management. If you don't see it, the plugin is off; an admin turns it on under Settings → Plugins.

[!TIP] Not sure how to split your own systems into services? Examples of how to set up services shows common setups, from Microsoft 365 to a web shop and a SaaS product, and the questions that settle most choices.

Who can use it

Needs the Service Configuration plugin.

Who	Can
Agent, Viewer, Auditor	Read the services of the units they work in, with their owners, teams and history.
Service Manager	Everything: add, edit and retire services and offerings, the accounts using them and their approvers, and set a service's status by hand.
A service's owner	Edit their service and set its status, whatever their role.
Administrator	Everything.

Each permission in detail: Who may do what.

Services in plain words

Think of the catalogue as the answer to three everyday questions:

• “What do we look after?” The services, each with a name people recognize.
• “Who do I talk to about it?” Its owner (who answers for it) and its support team (who fixes it).
• “If this breaks, what else breaks?” What it depends on, and what depends on it.

When one service comes in a few variants, such as Email: mailbox, shared mailbox and archive, those are its offerings: one level below it, sharing its owner and teams unless they set their own (offerings).

That is all a service needs to be useful. Everything else on the record (tiers, service hours, links) makes it more useful, but you can add it later.

Isn't this a CMDB?

A CMDB (configuration management database) records every server, application, database and network device, and how they connect. It is powerful, but it has to be kept up to date, usually by discovery tools, and few people find their way around one.

The service catalogue is the part of that picture that people work with every day: the services and how they depend on each other, at the level a team owns. It doesn't try to list every server. If you have a CMDB, link to it from the service's Links; if you don't, you don't need one to use services.

How dependencies work

Depends on says what a service needs to work. If one of those has a problem, this service can have one too.

It follows the whole chain. If Remote desktop depends on Customer VPN, and Customer VPN depends on Identity, a problem with Identity can reach both:

Business services

Remote desktop

RDP

can be affected too

Technical services

Customer VPN

VPN

can be affected

Identity

IDP

problem here

Business serviceTechnical serviceDepends onPoint at a service to see its chain

You only add the direct step; the desk works out the rest. Each service page shows The whole chain:

Part	Shows
If this has a problem	Everything that needs it, all the way up.
What it relies on	Everything it needs, all the way down.

Each shows the service in between (“through VPN”). Use it during an incident to see who else to warn, and before a change to see what it can touch.

[!WARNING] A loop (A needs B, and B needs A) isn't allowed. Add a dependency only when an outage really passes through it; otherwise every problem seems to reach everything.

In this section

• What a service is: Services, offerings, types, tiers and the lifecycle.
• The Services page: The list, a service's page, and importing services.
• Accounts and their approvers: Which accounts use a service, and who approves changes for them.
• Status, windows and freezes: How a service is now, and when changes may happen.
• Services on cases and portals: The service field on cases and incidents, and services on the portals.
• For auditors: Audit scopes, suppliers, reviews and exports.
• Permissions and the API: Each permission in detail, and what AI assistants and the API can do.
• Examples: How a few common setups could look, to borrow from.