Knowledge spaces
Overview
A knowledge space is the organising unit for knowledge. It gathers articles, SOPs, templates and solution blocks, and carries its own access management.
That is its real purpose: visibility is decided once at the space, not on every individual document. Anyone governing access per article no longer has a system after a hundred articles — they have a hundred special cases.
Core tasks
Create a space. New space requires a name; the slug is otherwise derived from it. The list shows space, type, visibility, access entries and status.
Set visibility. It determines who sees the space's content at all — and is inherited by everything inside it.
Manage access. The space's access list governs who may work in it. You pick people and roles from a list of names — the permission to maintain spaces is enough; you do not need role administration itself.
Archive rather than delete. An archived space disappears from daily use while its content stays readable. Deleting would destroy knowledge somebody searches for later.
Restrict to a brand. In the create and edit dialog you choose the brand — empty means: for all brands. With a brand, only users holding the permission in that brand see the space. When creating, the brand of the switcher in the header is preselected. Only someone who manages spaces across all brands may lift the restriction again (open the space to all brands) — otherwise brand knowledge could reach every brand unintentionally. The list and the space overview show the brand.
Arrange articles in the space. The space view shows the articles as a tree. With contribute access you arrange them there by dragging or by keyboard (see Knowledge articles).
Subscribe to a space. Subscribe in the header of a space keeps you up to date: you get a notification as soon as an article is published there or a published article receives a new version. Intermediate saves and drafts trigger nothing, and neither do your own changes. Anyone who can read the space may subscribe; if you lose read access, the notifications stop. Subscribed ends the subscription again. Whether the notifications also arrive by mail is set in your notification settings.
Run an onboarding handbook. A space of type Handbook is a curated reference with a fixed order — onboarding for newcomers is the typical case. Structure the topics in the tree; every article then shows the outline, the path to it and Previous/*Next*, so new colleagues can read the handbook from start to finish.
Fields in detail
The What it does column answers what changes in the system — not what the field is called. The grey name behind the label is the API field: the same thing runs under that name through automation, import and AI tools.
Creating and editing a space
| Field | Required | Values / format | What it does |
|---|---|---|---|
Name name | yes | text, max. 200 characters | What the space is called in navigation and selection. |
Address slug | no | text, max. 120 characters | The readable part of the address. Built from the name; changed by hand, existing links break. |
Description description | no | text | What the space is for. It appears on the overview and answers "where does my article belong?". |
Icon icon | no | text, max. 40 characters | The symbol in the navigation. |
Type type | no | wiki, handbook, SOPs, templates | What the space is meant for. Determines what content it takes and how it is shown — a handbook shows the structure, a wiki the search. |
Visibility visibility | no | whole organisation or restricted | The actual access switch. Whole organisation means every signed-in person reads along. Restricted opens the access list below. |
Access access | with "restricted" | list of people or roles with a level | Who may read and who may write. With no entry nobody but the creator sees anything — restricted deliberately means closed, not open. |
Curated isCurated | no | yes/no | Marks the space as a maintained body of knowledge. The AI assistant prefers curated spaces when citing. |
Brand brandScope | no | a brand in which you hold the permission | Limits the space to one brand. Only counts where you hold the permission for spaces — a membership without the permission is not enough. |
Archived archived | no | yes/no | Takes the space out of navigation and search without deleting it. The gentle route for knowledge you keep but no longer show. |
Settings & permissions
- Module
module.knowledge. knowledge.space.viewto see,knowledge.space.manageto create and administer.knowledge.brand.allfor spaces across every brand — only takes effect when the permission is granted for all brands.- The space inherits downward. What lies inside follows its visibility — an individual article's
portal release comes on top of that.
- The slug is permanent. Set it deliberately or leave it to derivation.
FAQ & troubleshooting
A colleague cannot find an article. Check the space first, not the article: without access to the space, the content is invisible too.
A space should go. Archive it. That takes it out of daily use without losing the content.
How many spaces make sense? As few as possible. Spaces are access boundaries — using them as a chapter structure builds access problems nobody wanted.
The brand cannot be removed. That requires the permission to manage spaces in all brands (or knowledge.brand.all for all brands).
A space should be visible to customers. Portal visibility arises per article through In portal, see Knowledge articles.