Feature Request

The Recommended Articles tab in the Salesforce integration matches on the case subject alone and returns the top five results. There is no way to configure which case fields feed the query. For support teams working structured cases, the diagnostic signal often lives in fields other than the subject — product type, model or material number, a fault code, the case description. Subject lines are frequently terse, or written by the customer rather than the agent, so matching on subject alone surfaces recommendations that miss the relevant troubleshooting content. Teams migrating from other knowledge platforms often have this today. Where an existing plugin passes case fields into search, moving to Document360 means losing it. Proposed behaviour Let an administrator configure which case fields contribute to the Recommended Articles query — standard fields and custom fields — rather than the query being fixed to subject. Optionally, allow a weighting or priority order so the most diagnostic field carries the most influence on the match. Related requests Related to “Salesforce - Relate Articles to Cases”, which covers linking articles to a case after the fact rather than improving how they are found. https://feedback.document360.com/feature-request/p/salesforce-relate-articles-to-cases Also relevant to “AI Search Support within Salesforce Integration”, since better retrieval in the widget and AI search in Salesforce address the same underlying gap from different directions. https://feedback.document360.com/feature-request/p/ai-search-support-within-salesforce-integration

Customer teams have no way to view or update who in their organization receives product and platform update announcements; changes currently require a manual request to be actioned on their behalf. Add a self-service control - for example, a distribution list or subscription setting in Project Owner/Admin account settings - so customer teams can directly view and manage who receives platform update and migration communications. Benefit: Lets a customer’s own team keep their announcement contact list current and ensures the right people see upcoming platform changes as soon as they go out, without depending on someone else to make the change for them.

MCP rate limits are fixed per plan, and increasing the limit currently requires manually contacting a Customer Success Manager or support rather than being configurable by a project administrator. Add a self-service option, for example in AI Settings > MCP or the MCP server analytics dashboard, where administrators can view their current limit, request or configure a higher one, and track the status of that request. Benefit: Administrators could scale MCP usage for concurrent or high-volume workflows more quickly and with clearer visibility into their current and available limits.

Currently, Document360 supports one-way synchronization with GitHub. It would be great to have a two-way sync feature, where changes made in Document360 are also pushed to GitHub. This would streamline workflows and ensure content is consistently updated across both platforms.

Teams that manage their development and project work in Azure DevOps currently have no direct way to connect that environment with their Document360 knowledge base. Add Azure DevOps as a supported integration or extension (comparable to the existing GitHub, Trello, or Asana connections), enabling knowledge base content to be linked to, triggered by, or kept in sync with Azure DevOps boards, repositories, or pipelines. Benefit: Teams working primarily in Azure DevOps could keep their documentation workflow connected to their existing project tracking and development activity, reducing manual duplicate data entry and keeping content better synchronized with ongoing work.

Teams that maintain source content in another documentation platform currently have no ongoing, lightweight way to push incremental content updates into Document360 after an initial migration. The only options today are a full migration-team engagement or a self-built integration against the content API. Build a connector or extension (comparable to the existing Zendesk, Slack, or GitHub extensions) that lets a team periodically pull updated content from a source platform into draft articles in Document360 for review and publishing, rather than requiring a custom-built API integration for routine content refreshes. Benefit: Teams can keep already-migrated documentation current on an ongoing basis without manually recreating articles or maintaining custom integration code each time source content changes.

AI assistants that lack a dedicated one-click connector require manual setup — copying a server URL or JSON configuration and completing OAuth by hand — before they can connect to a knowledge base. Add a one-click connector for Gemini, consistent with the existing one-click connectors already available for ChatGPT and Claude, so the connection can be established directly from the AI assistant or from the knowledge base’s MCP settings without manual configuration. Benefit: Users can connect Gemini to their knowledge base in a single step, reducing setup time and the chance of configuration errors during connector setup.

When a knowledge base widget’s architecture version is scheduled to change, there is currently no way for a project owner to view or confirm the effective migration date directly in the product. The date is tracked only through outside coordination, with no in-product confirmation of what is actually scheduled. Add a widget-level indicator in the Knowledge base widget settings showing the current version and, where a version change is scheduled or a rollback is in effect, the exact date it will take effect (for example, “Migrating to V2 on [date]”). Benefit: Project owners gain direct visibility into exactly when a widget’s version will change, and can verify that date themselves at any time, reducing the risk of an unexpected version change.

Integration with Azure DevOps so we can build a KB around releases, pipeline setups, artifacts etc.

Zendesk is deprecating API tokens, which are currently required for the Document360 Federated Search integration. Requesting alternative authentication support to ensure the integration continues working after API tokens are permanently deactivated. This is important to avoid disruption to existing Zendesk Federated Search integrations and provide a seamless transition to new authentication.