Feature Request

The AI response disclaimer ("AI can make mistakes. Please verify important information.") is displayed by default on the Knowledge Base site but is not available in the Widget. currently have to add it manually through custom JavaScript, requiring hardcoded translations for each language. Please support referencing existing Localization Variables within the widget to ensure consistency between the KB site and the widget while eliminating duplicate translation maintenance.

Problem Statement: The widget currently always opens to the Page Help tab by default, and there is no configuration setting to make the Knowledge Base tab the default or "sticky" tab instead. Customers who want users to land on, or return to, a broader Knowledge Base view (rather than page-specific help) must rely entirely on custom JavaScript to detect and override the default behavior, which is a workaround for a genuine, recurring configuration need rather than an edge case. Suggested Enhancement: Add a configuration option in the widget's Configure & connect settings (similar in spirit to the existing URL mapping default-behavior setting) that lets customers choose whether the Knowledge Base tab or the Page Help tab should be the default/active tab, including after the widget re-renders during a session. Customer Benefit: Eliminates the need for custom JavaScript for this common use case, reduces support tickets caused by custom scripts breaking during widget architecture updates, and gives customers a durable, supported way to control default tab behavior directly from widget settings.

Problem Statement: In Widget V2, the active tab (Page Help or Knowledge Base) is controlled internally by the widget's own state, and only the active tab's content is mounted in the page at any time. Customers who need the widget to consistently open to, or return to, a specific tab (most commonly the Knowledge Base tab) have no supported, official way to do this. The only current workaround is a custom script that simulates a click on the tab's DOM element and watches for changes with a MutationObserver, an approach that depends on internal DOM structure (element IDs, class names) that isn't a documented or guaranteed public contract, and that has already broken once when the widget moved from V1 to V2. Suggested Enhancement: Add a supported tab-switching command to the existing postMessage API and its mw() wrapper, alongside the existing show, hide, and toggle commands — for example mw('showTab', { tab: 'knowledgeBase' }) or an equivalent postMessage method. This would let customers switch tabs deliberately and reliably without relying on internal DOM structure. Customer Benefit: Removes the need for fragile, DOM-dependent custom scripts and MutationObservers to control tab state. Gives customers a stable integration point that won't break on future internal architecture changes to the widget, the same way show/hide/toggle already provide that stability for opening and closing the widget.

The Eddy AI chatbot widget loses its conversation history whenever: -> The page is refreshed -> The user navigates to a different page (non-SPA environments) However, the chatbot works as expected in Single Page Applications (SPA) where state is preserved. Based on our multi-page application - Webapp setup, we would like the chatbot to preserve the chat conversation. It helps our users to read the information and navigate within the application.

All JWT-enabled widgets in a project share a single client secret. Regenerating the secret from any one widget applies the change to every other JWT-enabled widget in the project immediately, with no option to limit the scope to a single widget. Teams that maintain separate production and test widgets within the same project cannot make JWT credential changes in their test widget without affecting their live widget. Workaround Limitations: There is no way to regenerate the client secret for a single widget; the change always applies to all JWT-enabled widgets in the project. Administrators have no visibility in Team Auditing into when or by whom the client secret was last regenerated. Requested Solution: Support independent JWT configurations per widget, so each widget can hold its own client secret. Specifically: Each widget should be able to generate and store its own client secret, independent of other widgets in the project. Regenerating the secret on one widget should have no effect on any other widget in the same project. The existing shared configuration should remain the default, with per-widget configuration available as an opt-in. Benefits: Teams can test JWT credential changes on a non-production widget without affecting live widgets. Accidental secret regeneration on one widget does not take down all other JWT-authenticated widgets in the project. Projects with multiple JWT-authenticated widgets can rotate credentials independently. Use Cases: Production and test widget isolation within the same project, multi-team widget ownership with independent credential management, staged credential rotation without coordinated deployments.

I would like a feature where we can fully edit the available fields in the ticket deflector, including adding new fields for specific information.

When a anyone attempts to generate a new JWT client secret, display a confirmation warning message. This warning helps prevent accidental JWT client secret regeneration. Because generating a new secret invalidates the existing secret, all active JWT integrations that use the previous secret will stop working until they are updated with the new secret. Warning message Generating a new JWT client secret will disconnect all existing JWT connections. To continue using the existing connections, you must update them with the new secret. Do you want to continue?

Doc360 recently released a change that broke code that was written that triggers launching the widget when clicking a custom button. When breaking changes are made that affect how widgets are displayed, customers should be notified of what changes have been made with guidance on how to update their code to accommodate the changes. There should also be some kind of versioning in place so customers have time to implement changes and refer to the latest version to avoid scrambling to fix unexpectedly broken widgets.

Support server-side widget JWT token generation via a backend credentials flow The Widget JWT OAuth2 endpoint ( identity.document360.io/connect/token ) returns 400 invalid_client when called server-side with the Client ID and Client Secret from the widget configuration. All combinations of grant types, scopes, Basic Auth, and body params were tested — all rejected. Use case: An enterprise in the media industry is building a custom SAP BTP integration in which the backend must generate a widget token before the widget loads in SAP Service Cloud V2. The browser-side widget SDK alone does not fit their server-driven architecture — the BTP backend needs to generate and pass the token as part of SAP session initialisation. Request: A supported server-side token generation endpoint for the widget JWT — a service account or backend credentials flow that allows a trusted backend to generate widget tokens without relying on the browser SDK.

In the Document360 chatbot, we currently have the option to customize the Eddy AI icon and name. However, the Eddy image displayed inside the chat panel remains unchanged. Providing the ability to customize this image as well would help maintain consistent branding throughout the chatbot experience.