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.
Archive rather than delete. An archived space disappears from daily use while its content stays readable. Deleting would destroy knowledge somebody searches for later.
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 | one of your brands | Limits the space to one brand. |
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.- 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.
A space should be visible to customers. Portal visibility arises per article through In portal, see Knowledge articles.