---
## Managing access for individual users and groups
In the **Manage content access** section, hover over a user or group to reveal three action icons:
| Action | Icon | What it does |
|---|---|---|
| **Edit** | | Modify the content access for a user. Click the **Save** () icon to apply changes or **Cancel** () to go back. |
| **Deny** | | Restrict the user's access to specific content. If a user belongs to multiple groups and one group has a restriction, the restriction takes precedence — the user will be denied access regardless of permissions granted by other groups. |
| **Remove** | | Removes the user's explicit access at this content level. The user may still be able to access this content if they have inherited access from a parent level. See [Understanding permission precedence](/help/docs/understanding-permission-precedence). |
You can also select checkboxes next to multiple users to apply bulk **Edit**, **Deny**, or **Remove** actions.
---
## Filtering the content access view
You can filter the user data on this page by clicking the tree-view workspace and language selection on the left, or by using the **Filter** option at the top right to filter by **Project**, **Workspace**, or **Language**.
---
## Assigning project-level access
To assign complete project-level content access to a user or user group:
1. Click **Assign project access** on the **Manage content access** page.
The **Assign project access: Complete project** dialog appears.
2. Click the **Change content role** dropdown and choose one of the content roles: **Editor**, **Draft writer**, or **Reviewer**.
3. The **Content access** field will be set to **Project** level by default.
--- ## 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. The user who performs the block retains access. For more information, see [Block user and user group access inheritance](/help/docs/block-user-group-inheritance). --- ## Best practices - Use the tree-view filter on the left to scope the access view to a specific workspace or language before making changes — this prevents accidentally modifying access at the wrong level. - Use **Deny** when you want to explicitly block a user from a specific content area even if they have inherited access. Use **Remove** only when you want to clear explicit access while keeping inherited access intact. - Assign project-level access at onboarding and use workspace or language-level access adjustments for exceptions only — this keeps your access model simple and consistent. --- ## FAQNOTE
If a user belongs to multiple groups with access to the same content, and one of those groups has restrictions, the restriction will take precedence. The user will be denied access to that content, regardless of the permissions granted by other groups.
If a user belongs to multiple groups with different permissions, which one applies?
If any group assigned to the user has restricted access to a category, the restriction takes precedence. The user will not be able to view the content, even if access is granted through another group.
Why is a newly created workspace not appearing in the content access settings for user groups?
If you've recently created a workspace and it's not appearing in the content access dropdown when assigning roles or permissions to user groups, it is likely because the workspace does not have any published articles yet. Workspaces without published content are temporarily excluded from the content access list, as there is no content to assign access to.
To resolve this, publish at least one article in the new workspace. Once published, the workspace will appear in the content access dropdown. If the issue persists, contact the Document360 support team.
If I grant access to a root category, will users automatically get access to its subcategories?
Yes, by default, access to a root category is inherited by all its subcategories. If you want to restrict an entire subcategory branch so that inherited access stops flowing into it, use Block Inheritance instead of manually denying individual users. See Block inheritance for more details.
Why is a user unable to access a category even though access is granted?
A user may belong to multiple groups with different access permissions. If any group assigned to the user has restricted access to a category, the restriction takes precedence. The user will not be able to view the content, even if access is granted through another group.
If a reader has two accounts with the same email — one standard login and one SSO — will their content access be merged?
No. Each account maintains its own content access determined by the assigned roles and permissions. The two accounts are treated independently.