Feature Request

Interactive Decision Trees (IDTs) can appear at the top of the search results on the knowledge base site. Unless the list is scrolled down, which is unlikely, their presence goes unnoticed, so relevant IDTs may never be discovered. A clear indication that IDT results are available is needed in the search results window, such as a label, tab, filter, or a note at the top of the results. This would make IDTs easier to discover and help readers reach guided troubleshooting content faster.

Currently, when exporting the knowledge base as a ZIP file, custom CSS configured for the live site is not applied to the exported output. This causes several styling inconsistencies that make the exported file difficult to use as a deliverable. Below are the specific issues observed: * Inline code styling does not match the live knowledge base. * Code block styling is difficult to read. * Table styling does not match the live knowledge base and is hard to read. * Hyperlink styling within articles does not match the live knowledge base. * Font family, size, letter spacing, and line height are not configured correctly. * LNB hyperlinks appear to be using default Document360 CSS instead of the custom styles. * Overall, custom CSS does not appear to be applied to the exported file at all. We would like to request that custom CSS be reflected in the HTML Export ZIP file so that the exported output visually matches the live knowledge base. This is essential for us to use the exported file for external distribution and documentation purposes.

Tags are scoped per language. A tag created in one language variant does not exist in the others — each is a separate entity that has to be created and applied independently. In a single-language project this is invisible. In a multilingual project it multiplies three things at once: the same identifier has to be created once per language it has to be applied separately to every language variant of every article the project tag ceiling has to absorb all the duplicates For a project publishing in six languages with around 13,000 unique product identifiers, this is the difference between roughly 27,000 tags and roughly 79,000. Where articles carry 50 or more tags each, a single article’s full language set can need several thousand individual tag applications. Material numbers, SKUs and product codes are identical in every language. They should not need a copy per language. The recent enterprise tag limits — 100,000 per project and 5,000 per article — mean this is no longer a blocker. But the headroom is largely being consumed by duplication rather than by distinct content, and the authoring effort of applying the same tag once per language remains. Proposed behaviour Allow a tag to be defined once and apply across all language variants of a project, with an optional per-language display label where the tag is visible to readers. Existing per-language tags should keep working unchanged, so this would be additive rather than a migration. Related requests Different from “Translation options”, which covers displaying a tag in the reader’s language. This is about a tag being a single entity rather than one per language. The two are likely related in the underlying translation engine. https://feedback.document360.com/feature-request/p/translation-options Also related to “Tags : Different Tags for workspace”, which raises tag scoping on a different axis. https://feedback.document360.com/feature-request/p/tags-different-tags-for-workspace

I would like the ability to export decision trees into flowchart software, like Vizio, Mural, or Lucidchart to be able to see all content and decision points. This will allow people to provide feedback.

Customer would like to export all visible analytics (Readers, Users, Searches, Feedback, etc.) in a single combined action rather than downloading multiple separate CSVs per analytics. Currently, this fragmentation forces manual consolidation of data, limiting the ability to create unified reports, integrate with external BI tools (Power BI, Hotjar), and tell coherent stories about documentation usage patterns. A unified analytics export would streamline analysis workflows and enable richer cross-analytics insights.

Feedback accumulates indefinitely. The Feedback Manager has date-range filters for viewing — 7 days, 30 days, 3 months, 1 year, custom — but those control what the list displays, not how long feedback is kept. There is no setting that archives or removes feedback after a defined period. Teams operating under data-retention policies they do not set themselves — internal governance, regulatory requirements, or regional data-protection practice — are often obliged to remove user-submitted content after a fixed period. With no retention setting, that obligation cannot be met in the product. The alternatives are deleting feedback by hand, which does not scale for anyone with real volume, or exporting the record and managing retention externally, which defeats the purpose of having a Feedback Manager. The 90-day cap on CSV export makes the external route harder still. Proposed behaviour A project-level retention policy: feedback older than a configurable period is handled automatically. Archival as the default, so historical feedback stays available for reporting without sitting in the active queue, with deletion available where a policy requires the content actually removed. An indefinite option should remain, since teams with no retention obligation will want current behaviour unchanged. Related requests Related to the Feedback Manager improvements covering search within discussion and history, and CSV export enhancements, which address the same problem of managing feedback at volume over time. https://feedback.document360.com/feature-request/p/feedback-manager

The megaphone opens the What’s New panel, but there is no signal that anything new is in it. A reader has to open the panel speculatively to find out whether something has been posted since they last looked. There is an existing dot indicator, but it applies to Read Receipts, not to What’s New announcements. So teams publishing updates through What’s New have no way to prompt readers to look. This matters most where announcements are operational rather than informational. Teams using What’s New to communicate procedural changes, safety-relevant updates, or anything readers are expected to act on are relying on readers choosing to check a panel that gives them no reason to. Proposed behaviour A dot or count badge on the megaphone when there are What’s New entries the reader has not yet seen, clearing once the panel is opened or the entries are viewed. Per-reader state where reader identity is available, falling back to a last-opened timestamp for anonymous readers.

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

We want to filter out archived articles in our service so the Eduphoria team doesn't spend time reviewing updates to articles that have been archived in Document360. Would it be possible to expose the archived status shown in the screenshot in the Articles API? The existing archived and hidden fields do not appear to reflect the status shown in the screenshot. This would help us identify and exclude archived articles from the updates processed by our service. Thanks.

Description: Several key AI-powered features, including Duplicate Content Detection and the AI Glossary Generator, are currently limited by language support, preventing customers from fully utilizing these capabilities in multilingual knowledge bases. Extending language support to English (US) and additional languages would enable customers to identify duplicate content, generate relevant glossary terms, and maintain consistency across documentation in their preferred languages. Expected Benefits: Enable customers to use AI-powered features across multiple languages. Improve content quality, consistency, and terminology management. Reduce manual effort in identifying duplicate content and creating glossaries. Increase feature adoption and overall product value.