Content access

You can control access to your knowledge base content at the project, workspace, or language level. Users and groups can have access enabled or restricted at the workspace or language level, as required.

Managing content role & access

To manage content role and access,

1. Navigate to Settings () > Users & permissions in the left navigation bar in the Knowledge base portal.

2. In the left navigation pane, navigate to Content access.

   You can view all the workspaces and languages available in the project.

   The Manage content access section is located on the right side of the screen. It displays the existing content access settings for your project's users and user groups. From here, you can review and manage access permissions to ensure the right users have the appropriate level of access.

3. In the Manage content access section, hover over the users or groups, and three icons appear:

• Edit ():  Modify the content access for a user and click the Save () icon to apply changes or Cancel () to go back.

• Deny (): Restrict access to specific content for the user.

• Remove (): Removes the user's explicit access to this content level. The user may still be able to access this content if they have inherited access from a parent level. To know more, refer Block inheritance.

3. Select the checkboxes next to users to apply bulk actions such as edit, deny, or remove.

4. Click the required icon to perform the respective function.
   

5. You can filter the user data available on this page by Project, Workspace, and Language using the Filter option at the top right, or by clicking the tree-view workspace and language selection on the left.

6. Click the Assign project access button to assign complete project-level content access to any existing users and user groups.

   The Assign project access: Complete project dialog appears.

7. Click the Change content role dropdown to choose one of the content roles: Editor, Draft writer, and Reviewer.

8. The Content access field will be set to the Project level by default.

NOTE

If a user belongs to multiple reader groups with access to the same content, and one of those groups has restrictions, the restriction will take precedence. This means the user will be denied access to the content, regardless of the permissions granted by other reader groups.

Block inherited accounts

The Block Inherited Accounts toggle becomes visible only when you select a specific workspace and language from the tree-view on the left.

When enabled, this toggle prevents all inherited and future users from accessing the selected workspace or language. However, your user will retain access since you performed the block inheritance.

For more information, read the article on Block inheritance.

Understanding permission precedence

In Document360, permissions follow a clear order: from the broadest level down to the most specific. Understanding this helps you predict who can access what, and why.

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 because the user receives access from a parent level instead of being added directly there.

• If you later give the user a permission directly at a lower level, that permission takes priority over the inherited one. This is called explicit access because the user was added directly at that specific level.

For example, 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. This is because a lower-level permission always overrides any inherited permissions.

 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.