Feature Request

Currently, inline commenting is limited to the Draft stage, which restricts reviews after publishing. Enabling this would help reviewers share suggestions or highlight required updates when they notice issues later. This would reduce the need to move articles back to draft and support a smoother post-publish review workflow.

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)

We would like to request the ability to add advanced filtering and sorting capabilities directly on the Knowledge Base landing page (not just within search results). Current Limitation At present, filtering based on structured metadata such as Custom Article Attributes is not supported on the landing page. Custom code is also not a scalable solution, as it requires manual updates whenever new content is added or modified. Proposed Enhancement Allow administrators to: Create and manage Custom Article Attributes (metadata fields), such as: * Release Version (v1.0, v2.0, v3.0) * Business Value (High, Medium, Low) * Functional Cluster (Create, Store, Manage, Platform) * Configurable / Non-Configurable (Yes/No) * Configurational Effort (High, Medium, Low) * User Persona (Admin, End User, Legal, Finance, Ops – multi-select) Enable these attributes as dynamic filters directly on: * Knowledge Base landing page * Category landing pages * Article listing views Provide sorting options such as: * Release Version (Latest first) * Business Value * Recently Updated * Alphabetical Business Use Case We maintain structured documentation aligned to release versions, user personas, and functional clusters. End users should be able to quickly filter content based on their role, release version, or configuration type without needing to perform manual keyword searches. This will: * Improve content discoverability * Reduce search dependency * Enhance user experience * Support scalable documentation growth Why This Is Important As documentation grows, structured filtering becomes essential. Many enterprise knowledge bases require metadata-based navigation rather than only keyword-based search. A built-in, dynamic filtering solution would eliminate the need for fragile customization code and provide a scalable long-term solution.

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.

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.

The Dashboard currently displays only this week’s tasks based on due date filters, which causes future assigned tasks to remain hidden. This creates confusion for users, as the counters do not reflect the total number of tasks assigned to them. The request is to add a visible counter on the Dashboard that shows the total number of assigned tasks, regardless of due date. Clicking the counter should redirect users to the full Tasks page for complete visibility.

Document360 to keep our documentation accurate by monitoring our codebase, detecting user-facing changes, and proposing updates the moment we ship. It surfaces needed edits to our team and generates context aware drafts so we can publish high quality docs faster. https://www.mintlify.com/blog/autopilot

It would be great to be able to publish our articles as an MCP server, so AIs can access them.

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