Feature Request

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.

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.

Customer requested an option to bulk update content access for multiple reader groups at once. Currently, access needs to be updated individually for each group, which is time consuming when managing many groups. A bulk update option would help administrators manage reader group permissions more efficiently.

I need to be able to filter the list of readers in the "Readers & Groups" section of the "Users & Security" tab. This would help me know who has already logged in from that reader group and who I need to re-send the activation email to so that they can activate their accounts. Currently, I have to scroll through the whole list of readers or search by a portion of their email address but I can still miss some.