---
title: "Understanding permission precedence"
slug: "understanding-permission-precedence"
description: "Understand Document360's permission hierarchy, including inherited and explicit access, to manage user and reader permissions effectively."
updated: 2026-06-20T07:26:15Z
published: 2026-06-20T07:26:15Z
canonical: "docs.document360.com/understanding-permission-precedence"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.document360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Understanding permission precedence

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]
> **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](/docs/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 |