Feature Request

Problem Statement: When an admin edits a reader group's content access level, readers whose individual access was previously set (even to "None") will not receive the updated group permissions, since individual-level settings always take precedence. There is currently no bulk way to clear individual-level overrides for all members of a group when the admin wants the group's access level to apply uniformly. Suggested Enhancement: Add a bulk action within "Edit reader group" (or the Readers & groups page) that resets the individual content access setting for all selected group members, so the group's permission level takes effect for those readers going forward. Customer Benefit: Saves admins from manually editing each reader's individual access after a group-level permission change, particularly for large reader groups, and reduces the chance that some members are left with stale, unintended access levels.

Problem Statement: Once a reader has any individual content access level set, that setting always takes precedence over their reader group's permissions, even when an admin's intent is for the group to control access. Admins who want a reader's access to fully depend on the group must remember never to touch that reader's individual setting, and there is no explicit mechanism to say "let the group decide." This creates administrative overhead and risk of misconfiguration, especially at scale (the KB confirms the product supports groups of up to 5,000 readers). Suggested Enhancement: Add an explicit "Defer to group access" option (or similar toggle) on the individual reader's content access setting. When selected, that reader's access is governed entirely by whatever reader group(s) they belong to, with no individual-level override in effect — distinct from setting individual access to "None," which today means no access regardless of group membership. Customer Benefit: Removes the need for admins to manually track and avoid touching individual settings to preserve group-driven access. Reduces configuration errors, especially during bulk onboarding or reorganization of large reader cohorts, and gives admins a clear, intentional way to express "manage this reader purely through their group."

Problem Statement: The migration to inherited permissions is a one-time, irreversible, all-or-project action. Admins cannot test how inherited access will look for specific reader groups or categories before committing, which increases risk for large or complex category structures. Suggested Enhancement: Provide a preview mode (e.g., a read-only simulation showing which readers/reader groups would gain access to which categories) or a staged rollout option (e.g., apply inheritance to selected workspaces/categories first) before the change is applied project-wide and permanently. Customer Benefit: Reduces migration risk and the need for extensive manual pre-migration auditing, giving admins confidence before making an irreversible change.

Currently, Document360 offers Public (viewable by anyone) and Private (restricted to specific users/groups) article visibility. There is no middle-ground option that allows a user to see the entire site's structure while still requiring authorization to read the content. Proposed Solution: Add a new accessibility level called "Protected Mode" or "Protected View." In this mode, users can see all article titles in the table of contents, including both public and private ones. However, when they click on any article, they are prompted to log in (if not already) and must have explicit viewing permissions to read the content. This provides transparency into the full knowledge base structure for authorized stakeholders (like certain customer tiers or partners) without granting immediate access to sensitive private content, improving navigation and manageability.

When you give specific users access to your articles (not on a category level but on an article level), it'd be useful if we can see a list of all articles and their respective users with access

When we try to update the content role for the team account, we see a blank UI page for the content role section. Here is a screenshot for reference:

Would like to have the ability for Reviewers to view a list of articles that need reviewing and filter the list for articles assigned to them as well as Categories and Tags. Having this functionality would help improve our Review workflow. The Bulk Operations permissions allows reviewers to see all articles that Need Review but it also allows them to delete articles which is NOT wat we want.

Allow users to comment on hidden articles without the ability to publish or edit published content. Use case: I want my product managers to be able to see hidden content/ drafts but be able to comment on them. I don’t want them to be able to edit the actual articles that are published on the portal (but give us reference/ comment/ notify) on top of them. So that only the technical writers will be the ones to do the actual changes (and not the PMs).

This banner is obtrusive and cannot be closed. I don't think it's necessary to remind users at all times that their access is limited; in fact, I think the constant reminder can actually create resentment among these users.

Displaying a message such as "Do you want to remove permissions from the articles?" when restricting access to the parent category would be beneficial. This message would prompt users to consider whether they also want to remove permissions from associated articles.