Feature Request

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.

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.

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.

One of our Customers requested the ability to customize the widget launch animation so it appears from the actual help button location, not always bottom-right.

This request was created on behalf of Gerard We have hidden the contributors list in the knowledge base. We would like to have an option to hide them under knowledge base widget too. Thanks.

Many of our customers are expecting a JWT configuration that supports a multi-tenant setup and the customer-specific (users using their specific tenants) authentication for the KB widget. This request is explicitly for multi-tenant JST configuration support for the KB widget

Currently, we don't have an option to edit the AI Chatbot's variables within the portal. We would like to edit the AI Chatbot's variables such as the 'AI desclaimer' shown. Thank you.

We have a requirement to configure URL mapping in the widget for multiple languages using the same application URL. Currently, our applications support language selection: * In some cases before login * In others after login However, the URL does not change when the language is switched. Expected behavior * When a user is in a specific module and language (e.g., English), the widget should display the mapped article in that language. * If the user changes the language (e.g., to German), the same article should automatically load in the selected language Current limitation * Document360 URL mapping relies on URL changes (e.g., language codes in the URL) * Since our application URL remains the same across languages, we are unable to map articles dynamically based on language selection Request We would like this to be considered as a product enhancement where URL mapping (or widget behavior) can support "language-based article mapping without depending on URL changes"

Ability to ensure that when users click Document360 knowledge base article links from outside the widget (such as from the product interface or support chat), the article should open directly inside the widget instead of a new browser tab. Currently, externally accessed links redirect users to a separate page, and there is no option to force them into the widget. The expected behavior is to automatically load the widget and display the respective article within it. This enhancement would provide a seamless and consistent user experience across all touchpoints.

Currently, URL mappings must be updated manually one by one, which is time-consuming for large datasets. We request a bulk import option (CSV or spreadsheet) to efficiently map article and product URLs.