Feature Request

In Reader self-registration for a Mixed Knowledge Base, associating an email domain with a Reader Group currently requires configuring the domain as Allowed. This behavior enforces domain restrictions and prevents self-registration from all other domains. This limitation makes it difficult to automatically group readers while still allowing open self-registration. The ask is for any other domains can self-register, but one specific domain needs to be added to a specific reader group. Request to provide a configuration option to: Assign readers to Reader Groups based on their email domain during self-registration Allow Reader Group mapping to function independently of domain allow/block rules This change would support scalable reader management in Mixed Knowledge Bases, enable customer-specific content visibility, and remove the need for manual reader assignment while preserving open self-registration.

Often, we need to take down articles, but we also need to be able to retrieve them later... and go back to it. So the ability to archive content is pretty important.

Hi team, Raising this feedback on behalf of Panaya. When importing a .docx file into an existing empty article, the system automatically overwrites the article title and slug based on the file name. This happens even when the user has manually set the title and slug earlier. Customer's workflow and concern: The user creates an empty article with a specific title and slug. They often share this slug/URL with their R&D team for integration on the Panaya application. After a few weeks, they import content from a Word file into the same article. The DOCX import unexpectedly overwrites the article title and slug. This breaks previously shared URLs and causes confusion Customer expectation: If the title and slug were manually defined, the import should not overwrite them, or the user should be prompted before changes.

Currently, we have options to add conditional content to articles. But there is no centralised place in the portal for content creators to see where the conditional content is used across the portals. Hence, it will save a lot of time for the Users to go to a central place to manage all the dependencies of conditional content.

Readers added to a specific workspace should get notified whenever a new article is published.

One of our customers who's default langauge is English (US) unable to use this feature at the moment. Implementing support for English (US) would be great.

This request was created on behalf of Gerard We have hidden the contributors list in the knowledge base. We would like to have an option to hide them under knowledge base widget too. Thanks.

Currently, Document360 allows us to configure status indicators (e.g., "New" or "Updated") that appear on the article header. However, these indicators are not visible on the search results page. Users must click into an article to see if it is fresh or recently revised, which adds friction to the information discovery process. Proposed Solution: Mirror the active status indicators from the article header onto the search result tiles/snippets. Ideally, the "New" or "Updated" badge should appear immediately adjacent to the article title in the search results list, or at the top right corner. Value to Users: Instant Verification: Helps users quickly identify the most current documentation. Increased Trust: Visual cues of "freshness" increase user confidence in the search engine's relevance. (Should be an easy win, since the "show status for X days" logic is already built into the backend, this is essentially a UI/Frontend update to expose existing metadata in a new location. I suggest making this an optional configuration that each user can decide to enable/disable)

Ability to copy/duplicate the Home page across language versions so that we don't have to upload images, recreate the wheel for every new language. We should just be able to replace the language text

Currently, the Find and Replace functionality does not support inserting variables. It would be very helpful to allow users to replace existing text with a selected variable using Find and Replace. This would significantly reduce manual effort when introducing new variables across a large number of articles and ensure consistency across documentation.