Knowledge Folders and Security

Knowledge — folders and security

How to organise a knowledge base into folders, and how to control who can read what.

For how it is built, see Knowledge — folders and security: Developer Guide. For the design reasoning behind the permission model, see Folders and permissions.

---

1. 📁 Folders

A document lives in exactly one folder. There is always a single honest answer to "where is it?", and moving something is a move rather than a copy.

To do this	Do this
Create a folder	New folder in the left panel, or right-click an existing folder to create one inside it
Rename or delete	right-click the folder
File a document	drag it onto a folder, in any view
Move a folder	drag the folder onto another one — everything inside comes with it
Move it out	right-click the document → Move out of its folder
Move it while reading it	the Move button on the article
Make a shortcut	hold Ctrl while dragging

A folder must be empty before it can be deleted. That is deliberate: deleting a folder full of documents is not a tidying-up action and should not be one click.

Shortcuts

Some documents genuinely belong in two places. Ctrl-drag leaves the document where it lives and puts a pointer to it in the folder you dropped it on.

🔑 A shortcut never grants access. It is only a pointer. If you cannot read the document, its shortcut does not appear either — you do not see a title you cannot open.

Right-click a shortcut to remove it. That takes away the pointer and leaves the document untouched.

Home

Home shows what is filed at the top level, plus the folders themselves. It does not list everything you own, any more than opening a disk lists every file on it. Filing a document therefore makes it leave Home — it has gone somewhere.

Searching and tag filters look everywhere, folders included, and each result says which folder it came from. A search that quietly ignored anything filed away would answer "no results" about articles that certainly exist.

---

2. 👁️ Four ways to look at the same thing

View	What it is for
List	full-width rows with a preview. Best when you are reading rather than filing.
Cards	a grid of tiles — title, author, date, tags. Best for scanning a folder you know.
Tree	the whole shape at once, folders and documents together. Best for learning how the knowledge base is arranged.
Details	a table of name, author, modified and tags, sortable by column. Best for spotting what has not been touched in a while.

Documents are listed alphabetically, with folders above them. Names containing numbers sort the way people expect, so Step 2 comes before Step 10.

Your choice of view is remembered per person. It is not shared with anyone else.

⚠️ The tree never filters itself. Clicking a folder in the tree selects it — it highlights, the trail names it, and a new folder or article goes there. It does not prune the tree, because showing the whole shape at once is the entire point of that view. Searching and tag filters still prune it, because those are questions about the whole knowledge base.

---

3. ☑️ Selecting several at once

Filing one document at a time is fine for one document. To move six, tick them.

• The tick is the mechanism. A plain click on a document always opens it, so selecting is done with the tick box on each row.
• Shift and click a tick takes everything between it and the last one ticked. The block follows the order shown on screen — so sorting the details view by a different column changes what a range means.
• Ctrl or Shift and click the document itself selects it instead of opening it, for when your hand is already on the row.
• Arrow keys move down the list · Shift + arrow extends · Ctrl + arrow moves without changing the selection · Space ticks · Ctrl + A takes everything on screen · Escape clears.

A selection survives searching, filtering and changing view. Tick six results for VPN, search for printer, tick four more, then move all ten.

With anything ticked, a bar appears above the list: Move them to files the lot into one folder, and Set who can see them changes the audience on all of them at once.

---

4. 🔒 Who can see what

Two separate controls decide who can read a document. They are easy to confuse because they answer different questions, and they combine.

Control	Question it answers	Where
Audience	what kind of person may see this at all	the editor, under Who can see this
Permissions	which named people	right-click → Permissions

🔑 Every control narrows. Nothing widens. A permission can never let somebody see something their audience excludes. Putting a customer on the list for an Analysts only article does not show it to them.

The audience is covered on the Knowledge page. The rest of this section is about permissions.

---

5. Open or Restricted — and what the list means

Every folder and every document is one of two things, and the list of people means the opposite thing in each. This is the single most important idea on this page.

Mode	The list is	An empty list means
Open (the default)	who is shut out — everyone else can see it	nothing is restricted at all
Restricted to chosen people	who is let in — nobody else can	nobody at all — the strictest setting there is

Reading the list without knowing which mode you are in will mislead you every time.

⚠️ An empty Restricted list is the tightest setting, not the loosest. It is not a mistake FreeITSM corrects for you — it means exactly what it says. The window tells you plainly when you have created one.

A list is never a mixture of both. That is why there is no allow and deny column to reconcile and no order of precedence to learn: an access list here cannot contradict itself, because a contradiction is not something it can express.

Switching between the two empties the list, and FreeITSM asks first. It has to — the same names would mean the exact reverse afterwards, and a list left behind in the wrong mode would silently do the opposite of what it says.

Who you can put on a list

Analysts, teams and individual portal users.

---

6. Inheriting from the folder above

By default a document uses the same permissions as the folder above, and so does a folder inside a folder. This is the ordinary case and the one to aim for: set permissions on a folder once and everything filed into it is covered, including things filed there later.

With the box ticked, the Permissions window shows the rules it is inheriting and which folder they come from, read-only. They are deliberately not editable there — those rules belong to the folder above, and changing them from inside one document would quietly change what everything else in that folder can see.

Where nothing above restricts anything, it says so in words. An empty list and "no restrictions at all" look identical and mean opposite things.

Untick the box to give one document or folder its own rules. Use this sparingly.

⚠️ Anything with its own rules is invisible from the outside. You cannot look at a folder and know what is true inside it. Permission exceptions in the left panel lists everything that does not follow its folder — it is the one screen that tells you where the surprises are. Check it occasionally; the count only goes up on its own.

---

7. ⚙️ What a restricted folder covers

When a folder is restricted, does that cover everything inside it, or only the folder itself? Both answers are reasonable and organisations genuinely differ, so it is a setting — Knowledge › Settings › Permissions, install-wide, administrators only.

Setting	Meaning
Folders are containers (default)	To read a document you must be able to read every folder above it. A locked cabinet is locked whatever is written on the file inside. Restricting a folder protects everything in it.
Folders are filing	Permissions belong to documents; folders only organise them. The nearest rules win and folders above add nothing. Choose this if your folders are a filing scheme rather than a security boundary.

Before the setting changes, FreeITSM tells you how many document readings would be gained or lost across your real content and your real people. Changing the answer to "who can read what" across a whole knowledge base is not something to do on a hunch.

---

8. Where the rules apply

The same access list is enforced everywhere an article can be reached. There is no route that reads round it.

Reached via	Notes
Analysts	browsing, searching, and the article itself
The self-service portal	the Help Centre customers see
The AI assistant	filtering happens before the model is shown the text, not after it answers
The website chat	can only ever use articles marked for the internet
The REST API	a key acts as the analyst it belongs to and sees exactly what that person sees

🔑 The AI is the sharp edge. An assistant that paraphrased a restricted document into an answer would leak it just as surely as showing it, and nothing would record that it had happened. The filter is applied at retrieval.

---

9. Administrators, and the trail

Somebody has to be able to get back into a folder restricted to nobody, so an administrator can always read anything. Without that floor, one mis-click could put a document permanently beyond every person in the building.

Every use of that floor is recorded — who opened what, and when — separately from ordinary reads. An override nobody can audit is not a safety net, it is a back door. Changes to permissions are recorded the same way.

⚠️ This is why "I removed myself from the team and I can still see it" is not a test. If you hold the administrator capability you will get in regardless of any list. To check that a restriction works, use an account that is not an administrator — and be aware that demo data often makes several accounts administrators.

---

10. 📱 On a phone

Everything above works on a phone. The article's actions — Share, Move, Permissions, Edit, Archive — sit in a row of icons pinned to the bottom of the screen, where a thumb is.

Attaching documents to an article lives in the editor, not on the article you are reading: reading is not editing.

---

Related pages

• Knowledge — the module overall, and the audience setting
• Knowledge — folders and security: Developer Guide — how it is built
• Folders and permissions — the design reasoning, and what was ruled out
• Mobile: Knowledge — the phone layout
• REST API: Knowledge — the same rules over the API