Feature Request

When an administrator tries to add someone as a Team Account using an email address that already exists under a different role in the same project, the system shows a generic error that does not explain the specific cause. Update the error shown when a Team Account email already exists under another role so it states the specific cause (e.g., that the email is currently registered as a Reader) and points to the appropriate next step, such as converting the existing account. Benefit:Administrators can immediately understand why an email address was rejected and resolve the conflict on the first attempt, without needing to guess at the cause or try multiple approaches.

Reviewers cannot access API documentation in the KB portal. However, admins can still grant reviewers access to API documentation workspaces through content access settings. This creates confusion for customers, who perceive the behavior as a bug and raise support tickets. Please remove this option to avoid such confusions.

Account status changes (activation and deactivation) are currently logged under the same general “account updated” event as unrelated profile changes, making it slow to isolate exactly when and by whom an account’s status was changed. Add dedicated “account deactivated” and “account reactivated” event types to the activity log and its event filter, separate from the general “account updated” event. Benefit: Teams can filter the activity log directly for activation or deactivation changes and immediately see who made the change and when, without reviewing unrelated entries.

When the user is trying to import the list of readers, hyphenated names and the names which have umlaut characters are showing the error " InvalidUserName" error. Some files pass the initial validation but fail to import without any indication of what the invalid username is. What problem the feature would solve ?: Many countries have people whose names are hyphenated. umlaut characters: This is a common character in the names of German people. If we allow these, the customers would be able to import the readers' names with hyphens and Umlaut characters as well.

I would like to be able to map contributor emails, so that if a contributor must be deleted and added with a new email, the article contributor is not lost in the transition.

When assigning content access to users or groups, admins need to grant access to a parent category while restricting access to only specific child categories and excluding others. Currently, unchecking child category boxes does not prevent access to those children, they automatically inherit the parent's permission. Admins must manually apply 'disable inheritance' to each excluded child category separately, creating operational overhead in large category trees. A native feature to explicitly exclude child categories from parent access would enable granular permission scoping without per-child flag management.

When a team account is converted, from a Document360 account to an SSO account, the portal, content access and the contributions made by that user are not retained. All the contributions are marked as anonymous. This is time-consuming to provide access once again to the same user and loss of contributions being revoked is a huge area of concern. We appreciate you taking the necessary actions to avoid this and make the necessary changes to retain access and contributions.

Allow users to create Reviewer accounts with Content Access = None during user creation and inherit permissions from the assigned Reviewer User Group, similar to other portal roles. Currently, this requires creating the user first and then editing the account, which adds unnecessary steps. Supporting this during user creation would provide a consistent permission model and improve the user management experience.

Currently, when editing a user's category permissions under Content Role & Access, it is difficult to identify whether a parent category has partial access granted through its child categories. The request is to display an indeterminate state (hyphen) for parent categories when only some of their child categories are selected, similar to how it is currently shown for Workspace and Language levels. Additionally, a more distinct visual indicator (such as a different color or style) could be considered to better differentiate between: Fully selected categories (checkmark) Partially selected categories (hyphen) Unselected categories (empty checkbox) This enhancement would improve visibility and make it easier for administrators to understand user permissions at a glance when managing category access.

Currently, reviewers are required to manually click the “Start Review” button before they can begin providing feedback on an article. This additional step adds unnecessary friction to the review process and may lead to confusion or delays, especially for new or occasional reviewers. Proposed Enhancement: Automatically initiate the review session when a reviewer opens the assigned article, removing the need for them to explicitly click “Start Review.”