Feature Request

Today, Sandbox operates independently from Prod, which creates practical issues. When testing KB Widget behavior, Prod has 600 plus URL mappings, and maintaining the same setup in Sandbox is not feasible, especially when Sandbox is meant for QA and Dev testing. While Dev and QA environments closely mirror Prod, the Document360 Sandbox does not. This limits its usefulness and turns it into additional overhead that requires frequent manual updates across Prod and Sandbox. Previously, we could deploy documentation to Dev and QA. This is no longer possible. The KB Widget router supports only one auth URL, and Sandbox contains outdated configurations. Keeping it current requires significant manual effort that should be automated. This feature request requires auto-sync of both content and all configuration and settings between Prod and Sandbox. This removes redundant manual work, keeps environments aligned, and allows Sandbox to be used for validation and testing without friction.

In Doc360, when a page redirects to a 404 link, the platform allows customization on the KB site, including company branding and custom messaging. However, when a user reaches a 404 link through the KB widget, customization is restricted. We want the same level of 404 page customization in the KB widget as on the KB site. This ensures a consistent and familiar experience for users who land on these pages due to broken links or missing articles.

In Doc360, when exporting content for offline use such as HTML, the export option becomes disabled if multiple users export at the same time. This disrupts workflow and blocks active tasks. Simultaneous exports also overwrite each other. If one export is available for download and another user starts a new export, the earlier export is replaced by the latest one. We need controls to manage this behavior. Options include a cooldown between exports or isolating exports so one user’s export is not affected by another’s.

I’m requesting an update to the semantic heading level used for the Article Summary in Document360. Currently, the Article Summary is marked with ARIA Level 1, which causes screen readers to announce it as an H1 heading, the same level as the article title. This results in multiple H1 headings on a single page. For proper accessibility and semantic structure, the article title should be the only H1, and the Article Summary should use ARIA Level 2 (H2). Accessibility Impact (WCAG 2.1) This change would improve compliance with the following WCAG 2.1 Success Criteria: • 1.3.1 – Info and Relationships: The current heading structure doesn’t convey a correct content hierarchy to assistive technologies. • 2.4.6 – Headings and Labels: The current headings do not clearly communicate the article’s structure when multiple H1 headings are used. Recommendation Please update the Article Summary’s ARIA heading level from Level 1 (H1) to Level 2 (H2). This change wouldn’t affect visual presentation, but would significantly improve screen reader accessibility and usability.

Currently, if an article is published, I can't see the comments on it, or leave a new comment. I need to click Edit to even see if anyone has left review feedback open on it. This makes it very hard to collaborate on pages and make small improvements together in a fast way. If I leave a bunch of comments on a page, and someone fixes one of them and publishes, the other comments are not visible anymore. That's a lot of feedback going to waste.

We are seeing inconsistent behavior with internal article links between the KB site and the KB widget. Example: An article titled 'Configure Doc360 for your platform' links to 'Preparing your platform before configuring Doc360.' On the KB site, the link works correctly and opens the target article. In the KB widget, the same link returns a 404. This occurs across multiple articles. If the link resolves correctly on the published site, it should resolve the same way in the KB widget. That is not happening. What causes this discrepancy? Is internal linking handled differently between the KB site and the KB widget? We need consistent behavior across all help center access points. If a configuration setting controls this, please point us to it. Our team has already raised this with support. If this is an implementation limitation, it needs to be addressed urgently. Broken internal links in the widget disrupts the documentation experience.

Currently, the CMD+F shortcut is overridden by the editor workflow instead of triggering the standard Find interface. This can be disruptive for users who rely on default system/browser behavior. Requesting a project-level option to disable the CMD+F override, allowing customers to use the standard Find functionality ( Browser) or retain the current behavior based on their preference.

I would like to include the article name in the cover page as this will give the option for the end users to view the title and understand what the PDF is about. Currently, we have to add the description manually. But the ask is to have a selection (to select any article title/category title) in the cover page section to make it appear automatically.

When changing an article’s workflow status, users can add a comment and mention assignees using @mentions. However, this comment is not visible in email notifications sent for the workflow change. Requesting an enhancement to include the workflow status update comment in the workflow change email notification, so assigned users and stakeholders have an improved visibility of the comments.

This request was created on behalf of We would like the option to configure individual column widths while maintaining an automatically fitted table layout on the page. Thank you.