Feature Request

You added a new "feature" without providing Document360 users with a way to disable it. Add an option in the settings to enable/disable each option (Copy page, View as Markdown, Open in ChatGPT, Open in Claude3) as needed.

Description: llms.txt currently includes every published workspace, so our API Reference (hundreds of endpoints) gets listed alongside our Knowledge Base content. The only exclusion option today, "Exclude from external search engine results," also removes the content from sitemap.xml and normal search, which we can't use since the API Reference needs to stay public and searchable. Ask: a setting (workspace-level, or at least API Reference–level) to exclude content from llms.txt generation only, independent of search/SEO visibility. Why: llms.txt should be a curated index pointing AI agents to product/architecture docs. Hundreds of individual endpoint entries dilute that; endpoint-level detail belongs in the API spec, not the index.

The customer requested a feature that allows both AI Glossary recommendations (green highlight) and inline comments (yellow highlight) to be visible simultaneously within articles. Currently, when an inline comment is added, the yellow highlight does not appear alongside the green, making it difficult for editors to identify where both glossary recommendations and comments exist.

Customer has requested the ability to filter table rows by column values. Users should be able to quickly narrow down the content displayed within a table based on specific criteria. Large documentation tables often contain extensive information. Readers reviewing prerequisites or requirements may only need to see a subset of data. Filtering would allow them to focus only on the rows that matter, improving usability and efficiency.

The table of contents does not make the full use of vertical space in a page. It is too truncated and you need to scroll a lot in longer articles to see the headings below. See the attached screenshot for a visual explanation. There was a similar request marked as 'Complete' but it doesn't work this way in our KB https://feedback.document360.com/feature-request/p/table-of-contents-full-length-of-right-column

Team, we have tested the KB widget implementation in our environment (bottom right), and we saw clicking the widget only opens the article that was configured in the settings without displaying any Related Articles underneath (image 1). Internally, we've decided to show no more than one article so we're not interested in "Show list of articles" option under "Update URL mapping" (image 2). Now, we're aware, Related Articles show on the published KB site at the bottom (Image 3), but the same isn't visible in the KB widget. Since the native functionality already exists, we want you to mimic this in the widget area - the white space below the configured mapping (image 4).

A customer has highlighted that they previously had the "Related Articles" section customized to appear in the right-hand navigation of the article view. In the site 2.0 version, this section appears at the bottom of the article, significantly reducing its visibility to end users. Here’s a direct quote from their feedback: "The Related Articles is displayed at the bottom of the article. The end users can’t even make out the presence of this link. Previously in 1.0 we had got it customized and was made visible in the right column. I need the same customization this time as well." Business Need: This customer had this feature customized in the earlier version and is now explicitly requesting its restoration in the current version. The ask is rooted in: Preserving user behavior patterns established in v1.0 Improving UX and knowledge flow Maintaining UI/UX consistency for returning end users Proposed Enhancement: Enable configurable placement of the Related Articles section with the following options: Sidebar (Right) Footer (Current Default) Benefits: Improved Visibility & UX: Users are more likely to see and click on related content when it's in the right navigation. Consistent Experience: Supports continuity for customers migrating from old version who relied on that layout. Increased Content Engagement: Better positioning drives deeper knowledge base usage and inter-article navigation.

The current behavior that article redirect rules only apply after publication, not for Preview, mean that for articles with a slug change, we have to publish them for quality checking instead of just using Preview. This creates unnecessary churn. It's not intuitive that article redirect rules don't apply to Preview as well - it feels like a bug. Could you perhaps fix this behavior? Many thanks :)

In Widget settings, we want "URL Mapping" to be grouped by Category or at least a folder. Our use case is to map ~500 URLs to our help buttons. Currently, these are all shown in one place without the ability to search for or sort them (image 1). Similar to what you have in "Content Tools" for Tags, we want it to be implemented for URL Mapping (images 2 & 3). For Tags, we have a list of individual tags in one tab, and the other tab has the Groups they belong to. This will not only save time, but will allow users to organize their URL mappings better.

In one case, the AI summary introduced a small but significant error. We would like to be able to manually fix the summary text