Content access

You can control access to your knowledge base content at the project, workspace, or language level. Team accounts and groups can have access enabled or restricted at each workspace or language level based on your requirements.

Managing content role & access

To manage content role and access,

1. Navigate to Settings () in the left navigation bar in the Knowledge base portal.

2. In the left navigation pane, navigate to Users & security > 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 team accounts and team account 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 Team accounts or groups, and three icons appear:

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

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

• Remove (): Delete the team account from the access list.

3. Select the checkboxes next to team accounts 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 Team account 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 Team accounts and Team account 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 team accounts from accessing the selected workspace or language. However, your team account will retain access since you performed the block inheritance.

For more information, read the article on Block inheritance.

Understanding permission precedence

Document360 determines a user’s effective content access by evaluating permissions across different hierarchy levels and sources (individual vs. group). The system applies a clear precedence model to ensure consistent and predictable outcomes.

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.

• If you set a permission directly at a lower level, it overrides the inherited permission.

For example, if User A is given Editor permission at the Language level (English), that Editor access automatically applies to all Categories and Articles under English because permissions set at a higher level are inherited. However, suppose you later assign Read permission to User A at a specific Category level within the same English language. In that case, the Category-level permission will apply to that Category and all its Articles. This is because a lower-level permission always overrides any inherited permissions.