In Document360, permissions follow a clear hierarchy from the broadest level down to the most specific. Understanding how permissions flow — and when one overrides another — helps you predict who can access what, and why.
This applies to both user permissions (portal access) and reader permissions (knowledge base site access).
Permission hierarchy
Permissions are inherited in this order, from the highest level to the lowest:
Project → Workspace → Language → Category → Article
- Permissions set at a higher level automatically apply to all lower levels. This is called inherited access — the user receives access from a parent level rather than being added directly at that level.
- If you later give a user or reader a permission directly at a lower level, that permission takes priority over the inherited one. This is called explicit access — the user was added directly at that specific level.
Example: Inherited vs explicit access for users
User A is granted Editor access at the English-language level. This automatically flows down to all categories and articles under English. This is inherited access.
If you then assign Reviewer permission directly on a specific category, that explicit access overrides the inherited Editor permission — making User A a Reviewer for that category and everything inside it, while remaining an Editor everywhere else under English. A lower-level permission always overrides any inherited permission.
NOTE
By default, permissions always flow downward. If you need to stop that flow entirely at a specific level — so that no inherited access reaches it at all — use Block inheritance. This is different from overriding a permission; it removes all inherited access completely and lets you start fresh. See Block inheritance.
Example: Inherited vs explicit access for readers
Reader A is given access at the English-language level. They automatically get access to all categories and articles under English. This is inherited access.
If you later give Reader A direct access to a specific category, that direct permission becomes the active permission for that category and everything inside it, while the rest of the content under English continues to use the inherited access.
How Deny works
The Deny action overrides all other permissions — including inherited access. If access is denied for a user or reader (or their group) at any level, they will not be able to access that content, even if they have inherited access from a parent level.
If a user belongs to multiple groups and one group has a Deny on a piece of content, that Deny takes precedence over access granted by any other group.
How Remove differs from Deny
| Action | What it does |
|---|---|
| Remove | Removes the explicit access assigned at this level. The user may still have access through inherited permissions from a parent level. |
| Deny | Actively restricts access to this content regardless of inherited permissions. The user cannot access it even if a parent level grants access. |
Summary table
| Scenario | Result |
|---|---|
| Access granted at project level | User has access to all workspaces, languages, categories, and articles |
| Access granted at workspace level | User has access to all languages, categories, and articles inside that workspace |
| Access granted at language level | User has access to all categories and articles under that language |
| Explicit access assigned at category level | Overrides inherited permission for that category and everything below it |
| Deny applied at any level | Blocks access at that level and below, regardless of inherited permissions |
| Remove applied | Clears explicit access; inherited access from parent level may still apply |