Feature Request

Current behavior: Reader Group-based access restrictions currently work at the category, subcategory, and article level, if a reader group doesn't have access to a category, that restriction is correctly enforced there. However, no Reader Group conditions exist on the Home Page (landing page). As a result, customers see all home page tiles, including tiles linked to categories they don't actually have access to. Example: A home page tile is linked to an article from Category X. Category X is restricted for a given reader group. That reader group still sees the Category X tile on the home page. When they click it, they're taken to an error/access-denied page instead of being blocked from seeing the tile in the first place. Problem: This creates a frustrating customer experience, specifically in cases when customer sdont have access to half of the categories. Becuase, what ends up happening is customers see mix of tiles for content they can and can't access, and clicking into half of them when expecting to view something, ends up with broken views and access errors. They then really have to rely on memory to know which tiles are accessible and which are not. It also inadvertently reveals the existence of categories/content that should be hidden from that reader group entirely. Requested behavior: Extend or tie Reader Group permission enforcement to the Home Page. If a home page tile is linked to a category (or subcategory) that a reader group doesn't have access to, that tile should be automatically hidden from the home page for users in that reader group, so customers only ever see tiles for content they're actually permitted to access.

The customer bulk-imported readers as part of onboarding a large user base. A portion of them have not activated their accounts. With no bulk-send option, the customer would have to manually trigger "Send Activation Email" individually for every unactivated reader, which is highly tedious and doesn't scale for accounts with large reader lists. Add a bulk action to select multiple readers (e.g., via checkbox selection or filter, such as "not yet activated") and send activation emails to all of them in a single action, similar to existing bulk actions like deactivate/delete/convert to user.

Currently, users do not have an option to check, in bulk, whether activation emails have been sent to Readers or not. Raising this request to support the following in bulk: Identify Readers for whom the activation email has not been sent. Identify Readers for whom the activation email was sent but not delivered. This would help administrators efficiently track activation email status in bulk and take the necessary follow-up actions.

Teams that want to show different widget content to individual readers currently have only one option: implement full JWT authentication. For teams without an existing identity/auth layer suited to JWT, this is a significant integration lift relative to the narrower need of restricting content per reader. Suggested Enhancement: Provide a lighter-weight mechanism for individual reader-level content restriction in the widget that does not require implementing a full JWT authentication flow, for example, a simpler token or invite-based reader identification method scoped specifically to the widget. Customer Benefit: Teams can tailor widget content to individual readers without needing to build and maintain a JWT authentication integration, lowering the technical barrier to adopting reader-level content control.

Category and reader group management is too high level for managing content access. There is conditional content blocks, but you can't do that with a whole article. It would be beneficial to turn on/off singular articles for different readers/groups. It would also be necessary to identify and track which articles this has been done to. A mass edit function to edit or remove this functionality from more than one article at a time would also be helpful. This is specifically aimed at internal company kb articles, where the goal is to make things accessible to larger groups, and restrict manager related articles without having to manage excessive categories. This would also be used to define shared content across countries where some articles may be universal while the bulk may be different amongst countries.

Problem Statement: The Export CSV button's behavior is more nuanced than a simple enabled/disabled state: it's fully disabled for JWT-only reader groups, but for mixed-authentication groups it silently exports only the Normal and SSO readers while excluding JWT readers, with no indication in the UI that the export is partial. Admins may not realize the exported CSV is incomplete, which risks incorrect assumptions during audits or compliance reviews. Suggested Enhancement: Add contextual messaging that covers both cases: (a) a disabled-state tooltip when a group is entirely JWT-authenticated, explaining why, and (b) a visible note or export-summary line when a mixed group's CSV is generated, clarifying that JWT readers were excluded and why. Customer Benefit: Prevents admins from unknowingly treating a partial export as a complete reader list, and reduces support tickets from confusion over disabled or incomplete exports.

Problem Statement: Document360 does not store reader details for JWT-authenticated readers, since authentication happens externally. As a result, JWT readers within a reader group can never be included in a CSV export, even when the rest of the group (Normal or SSO readers) can be. Based on the 10 most relevant KB articles searched, no verified API or export mechanism exists for retrieving JWT reader identity or group membership data from Document360. Suggested Enhancement: Provide an official API endpoint or portal reporting view that surfaces JWT reader group metadata (group ID, title, description, content access scope) to the extent technically feasible without Document360 storing full JWT reader identity records. Customer Benefit: Gives admins on JWT-authenticated or mixed-authentication projects a supported way to audit and report on JWT reader group access, closing a gap that documentation alone cannot solve.

In the Edit Reader Group window, when a user searches for a reader using the Search email field and then removes one of the matched readers, the list and count do not retain the search/filtered context. Instead, the view resets to the default (unfiltered) list, and the count reflects total group membership rather than the remaining filtered results. Example: Search returns 4 matching readers ("1 to 4 of 4"). User removes 1 reader. Expected: "1 to 3 of 3" (remaining filtered results). Actual: count resets to "1 to 20 of {total group membership}." Additional issue: The modal window obscures the name of the reader group being edited, making it difficult to confirm which group is being modified, particularly impactful for customers working across multiple groups in parallel (e.g., split-tab workflows for moving readers between groups).

Currently, the Reader List is only accessible when a project is configured as Private or Mixed. If readers were initially added while the project was in Private/Mixed mode and the project is later changed to Public, admins can no longer access the Reader List. To convert these readers into users, administrators must temporarily change the project back to Private/Mixed, perform the required actions, and then switch it back to Public. This workflow is cumbersome and impacts usability. Please consider making the Reader List accessible for Public projects as well, allowing administrators to manage existing readers without changing the project's access mode.

Problem Statement: After migrating to inherited permissions, categories and articles that existed before the migration retain their access but do not visually appear as "selected" in the Reader Group settings screen. Admins must manually re-select these items to make the UI match actual access, which is a manual, error-prone workaround for a display inconsistency that the product itself creates. Suggested Enhancement: Automatically update the Reader Group UI so that any category or article to which a reader group has access (whether granted before or after migration) is shown as selected, without requiring manual re-selection by the admin. Customer Benefit: Removes a confusing, support-generating discrepancy between actual permissions and what the UI displays, and eliminates the manual clean-up step admins currently have to perform after migration.