Plan requirement
| Subscription | Suite Growth or higher |
| Access | Admin |
You can create up to 100 categories, nested five layers deep, and a service can sit in more than one of them. Keeping the catalog usable is mostly about naming and about retiring things, and retiring a service means unpublishing it rather than deactivating it, because there is no deactivate.
Work with categories
- In Knowledge admin, click Service catalog in the sidebar.
- Click Create and select Category, or use the add icon in the Categories panel.
- To change one, select it, click Actions, then Edit, and click Save.
- To remove one, select it, click Actions, then Delete, and confirm.
Deleting a category takes everything under it
All of that category's subcategories are deleted too, and any services in it become uncategorized. The services survive, which is the reassuring half, but they drop out of the structure and nothing points at them until you file them again.
So before deleting a branch, note what is under it. Five levels of nesting is enough depth to lose track of a subcategory you were not thinking about.
A service belongs to categories, it does not move between them
Because a service can sit in more than one category, filing is additive rather than exclusive. That is useful where a request genuinely belongs in two places, such as a laptop under both Equipment and New starters, and it is a trap if you treat it as a move and leave the old placement behind.
There are bulk actions for both halves of that: categorising services in bulk, and removing them from a category in bulk. The second is the one that clears up after a reorganisation, when the old placement is on thirty services and nobody wants to open thirty.
What you can and cannot edit on a service
| Title, description, fields, categories | Editable at any time. |
| The service request form | Created automatically with the service. You cannot edit or delete it. |
| Unpublish | Makes the service unavailable to users. You can publish it again later. |
| Delete | Permanent and cannot be undone. The object and the ticket form go with it, and lookup relationship fields pointing at it show an empty value. |
Unpublish is almost always the right choice for something no longer offered. Delete is for something created by mistake.
It has a second use: unpublish a live service and you can then save your changes as a draft, so a rewrite does not have to happen in front of requesters. That is the safe way to change something people are already ordering.
Name categories by what people want, not who provides it
Requesters do not know which team handles what, and should not have to. "Devices and equipment" works; "Infrastructure Services" only works for people who already know.
The ceiling is 100, the useful number is far lower
Five to seven top-level categories is enough to group meaningfully and few enough to scan without reading. Past that people stop browsing and start searching, and a catalog only usable by search did not need categories. Nesting is there for depth within a branch, not for accommodating more top-level entries.
Write a real description
One line saying what the requester gets and roughly when. That line prevents most of the "is this the right one" tickets, and it is the difference between a catalog and a list of nouns.
Check routing after any change
Once or twice a year, look at request counts per service. A service with none in a year is either not needed or not findable, and both call for a decision. After changing one, submit a test request and see where it lands.
Comments
0 comments
Article is closed for comments.