Module configuration
Templates & collections
Templates and template collections now live in one workspace per module, with a hierarchy view that shows which template sits in which collection and lets you reorganise it by dragging.
Updated Jul 25, 2026
Configuration · Modules · 4.11
A template is a prefilled record: the fields, the questions and the defaults someone gets when they raise a request, register an asset or write a knowledge base article. A collection groups those templates so the person raising the request sees a short, sensible menu instead of a list of eighty.
The two used to live on separate screens. They are now one workspace per module, which is the point of this chapter: the relationship between a template and its collection is the thing you actually design, and you cannot design it while looking at two lists that each hide half the picture.
Why this matters to the business
"Nobody can find the right request form"
Collections turn eighty templates into six recognisable groups.
"Every ticket needs three follow-up questions"
Ask them in the template's questions, so the answer arrives with the request.
"Orphan templates nobody maintains"
The hierarchy shows what is not in a collection, so it stops being invisible.
"Reorganising took a change request"
Drag a template into another collection and it is done.
Four families, the same workspace
Every family has its own workspace, reached from its own module in Settings. The screen behaves identically in all four, so you learn it once.
| Family | What its templates prefill |
|---|---|
| Ticketing templates | Request and incident forms: the intake the requester fills in, with its questions. |
| Asset templates | Recurring asset types with their standard fields and specifications. |
| Configuration item templates | The CI shapes your estate is built from, so every entry is comparable. |
| Knowledge base templates | The house structure for articles: same sections, same order, every time. |
Three views on the same data
Hierarchy
The tree: collections, sub-collections and the templates inside them, plus a group for everything that is not in a collection. This is where you reorganise.
Collections
The collections on their own, for naming, ordering and deciding who sees which group.
Templates
The flat list, for when you know the template you need and just want to open it.
Working in the hierarchy
Each row shows the name, the type and the code, so you can tell two similarly named templates apart without opening them. Search, expand all and collapse all keep a large tree manageable.
| Action | What it does |
|---|---|
| Add collection, add sub collection | Build the grouping, one level deeper where a group is genuinely large. |
| Add template | A new template, created straight into the collection you are standing in. |
| Drag a row | Move a template to another collection. The move is saved immediately. |
| Go to questions | Jump from a template to the questions it asks, which is where most of the configuration work sits. |
| Duplicate template | Clone a working template rather than rebuilding a near-identical one. |
| Remove from collection | Take a template out of its group without deleting it. It lands in "Not in a collection". |
| Delete | Available for both templates and collections, each behind its own permission. |
Old links keep working
The standalone collections screen is gone, but the URLs are not broken: a link to the old collections route redirects into the same workspace with the Collections view already open. Bookmarks, dashboard widgets and links in your own documentation keep working, so there is nothing to clean up ahead of time.
Reading a template and managing a collection are separate rights per family, so you can let a module owner curate the grouping while only a smaller group may delete templates.
Which decisions will you make?
How deep does the grouping go?
One level is usually enough. Use sub-collections only where a group is genuinely too big to scan.
Group by what?
By the requester's language ("Something is broken", "I need something"), not by your internal department structure.
Who owns a family?
Name an owner per family. Templates rot quietly when everybody may add one and nobody prunes.
Naming and codes
The code shows in the tree and in reporting. Agree a pattern before you have eighty of them.