Feature Request

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.

The customer reported that the KB widget takes around 8 to 10 seconds to load on the first login and requested faster performance. They expect the widget drawer to open instantly and the content to load within 2 seconds.

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.

Currently, the Document360 widget relies on URL-based mapping to display contextual help. This approach does not work effectively for Single Page Applications (SPA), where the URL does not change during navigation. Customer require the ability to trigger the widget contextually using a custom identifier (e.g., Help Key, screen ID, or event-based trigger) instead of relying on URL changes. This would allow applications to dynamically display relevant articles based on user interactions or screen context.

We are trying to embed the Ask Eddy widget into a new application. We found the product enforces Cross Origin Embedder Policy (COEP) as part of the product’s security baseline, and this configuration cannot be changed. With COEP enabled, browsers require all cross origin resources such as Document360 to explicitly allow embedding. Currently, the Document360 widget assets do not include the Cross Origin Resource Policy header required for this scenario, which results in the widget being blocked. To support COEP enabled applications, the Document360 widget assets need to include the following response header: Cross-Origin-Resource-Policy: cross-origin Thank you.

Posting on behalf on Cycode. They use URL mapping a lot and have requested to have a sorting feature as they are unable to find the URL mapped names. Their reqyest is to have a basic alphabetical ordering alongside sorting options which should also includes dates. This way, they needn't scroll through all the pages to find one.

One of our customer requires the ability to open a specific, predefined documentation page directly within the help widget when triggered from contextual elements such as tooltips or buttons inside their application. The current implementation relies on AI prompt-based retrieval, which may return multiple or inferred results and does not guarantee deterministic navigation to a single intended article. This limitation prevents precise in-app guidance and creates friction in contextual help workflows, particularly for production environments that require predictable, page-level deep linking. The requested enhancement is to support direct article selection and loading within the widget, independent of AI prompt matching, while remaining compatible with existing contextual assistance configuration.