Feature Request

When a credential or backend-integration-related change occurs, teams running the widget across many downstream environments have no way to know ahead of time, so they discover disruptions only after they happen. Provide an opt-in notification (email, webhook, or status-page entry) that alerts project admins when a change that could affect an active widget or integration is rolling out, so they can verify their setup proactively. Benefit: Teams managing the widget across multiple connected environments can confirm everything still works on their own schedule, instead of reacting after something breaks.

Improve the existing confirmation prompt / add new ones wherever possible for sensitive user actions to include clear impact details and next steps, and introduce traceable audit logs for all such actions. Problem Statement For eg: A confirmation prompt already exists for actions such as widget API key regeneration. However, the current message, “This will replace the current token and cause any code referencing the old token to not work as expected,” is insufficient. It tells the user what will break but does not tell them what they need to do next, to update it across their external sites and integrations; otherwise, they will stop working immediately. Additionally, there is no accessible audit trail capturing when such actions occurred, who performed them, and what changed. When issues arise, the customer cannot independently verify what happened, requiring escalation to the product team for backend log access each time. Proposed Improvements Enhanced confirmation prompt: Expand the existing warning to include the full impact and the required next steps. Example: “Regenerating this token will immediately invalidate the current key. Any websites or integrations using the old key will stop working until you update them with the new key. Please ensure you update the widget script on all external sites after regenerating. For guidance, refer to [link to documentation]. Do you want to continue?” Traceable audit logs: Maintain a comprehensive, timestamped activity log at the project and team level that captures all sensitive user-initiated actions, including the action performed, the user who performed it, the timestamp, and the before/after state where applicable. This log should be accessible to project admins. Expected Outcome Users are fully informed of the impact and their required next steps before completing a sensitive action Accidental or uninformed changes are significantly reduced Customers can independently verify what happened and when

Currently, when an article is moved or reordered, Team Auditing only displays the article name and the workspace name. The audit log does not show the complete category path where the article was moved, making it difficult to identify the exact destination. For example, instead of only showing the workspace name, the audit log should display the complete path, such as: Workspace name > Category name > Sub category name This would make it easier to understand exactly where an article was moved or reordered.

The current Team Auditing logs provide only high-level event descriptions for certain actions, which makes it difficult to clearly identify the exact change that occurred. For example, when a notification channel is modified (such as updating the channel name or changing the email address for an email channel), the audit log records the event simply as “Updated notification channel.” It does not indicate which specific attribute was changed or provide additional context about the modification. Similarly, when an article visibility setting is updated, the audit log records the event as “Changed article visibility.” However, it does not specify whether the article was hidden or made visible, which can create ambiguity when reviewing audit history. Enhancing the Team Auditing logs to include more descriptive details about the action performed would improve clarity and traceability. For example, indicating the specific field updated in notification channels and clearly stating whether an article was hidden or unhidden when visibility changes occur. This would help administrators better understand system activities and track configuration changes more effectively.

The current Audit Log displays activities from all workspaces, making it difficult for users to find relevant events. Add a Workspace filter to allow users to view audit logs for a specific workspace, improving usability, troubleshooting, and audit efficiency for organizations managing multiple workspaces.

Problem Statement: Client secret regeneration events for the knowledge base widget and AI chatbot are not currently captured in Team Auditing. When a widget stops authenticating unexpectedly and no team member recalls making a change, there is no audit trail to identify who regenerated the secret or when the change was made. This gap was acknowledged in the KB as a known limitation. For security-critical actions that immediately impact all JWT-enabled integrations across a project, the absence of an audit record creates significant operational and compliance risk. Suggested Enhancement: Extend the existing Team Auditing system to capture client secret regeneration events for the knowledge base widget and AI chatbot, consistent with the audit logging already in place for JWT SSO configuration changes (which logs primary and secondary token regeneration events). Each log entry should record the action type, timestamp, the identity of the administrator who performed the action, and the widget or chatbot affected. Customer Benefit: Administrators can quickly identify the source and timing of authentication failures caused by unannounced secret regeneration. Teams operating in regulated environments gain the audit trail needed to meet access control and change management requirements. Reduces mean time to resolution for JWT authentication incidents.

Summary: Add the ability to save filter combinations as named views (and/or reflect active filters in the URL) on the Team Auditing page, so admins don't have to manually re-apply filters every time they visit or refresh the page. Problem: The Team Auditing page (Settings → Team auditing) offers several filters — Events, Audit date, and Activity by user — which is great for narrowing down a large activity log. However: None of the filter selections are persisted. Every time the page is refreshed or revisited, all filters reset to default and have to be reconfigured from scratch. The page URL (e.g. .../settings/team-auditing?tab=teamAuditing) doesn't encode the applied filters, so there's no way to bookmark a specific filtered view or share a direct link to it with a teammate. With a long list of possible events and users to choose from, re-selecting the same combination repeatedly (e.g. "show only Publish/Unpublish events by a specific author in the last 7 days") is tedious and time-consuming, especially for admins who check audit activity on a recurring basis (daily/weekly reviews, compliance checks, etc.). Suggested Solution: Persist filters in the URL as query parameters — so that applying filters updates the URL, and loading that URL (via bookmark, refresh, or a shared link) restores the exact same filtered view. This alone would solve the bookmarking/sharing problem with minimal UI change. Saved filter views/presets — allow users to save a named combination of filters (e.g. "Weekly publish review", "My team's edits") and quickly switch between saved views from a dropdown, similar to saved views/filters in other list-heavy areas of the product. Remember last-used filters per user (optional, as a fallback) — even without explicit "save," retaining the last applied filter state per logged-in user for that page would reduce repetitive setup. Why this matters: Saves repeated manual effort for admins/teams who audit activity regularly (e.g. content ops, compliance, workflow review). Enables sharing a specific filtered audit view with a colleague or manager via a direct link, instead of describing which filters to apply. Brings Team Auditing in line with other tools where filtered views are typically bookmarkable or saveable. Where this applies: Settings → Team auditing → Team auditing tab (filters: Events, Audit date, Activity by user). The same idea could extend to the Audit configuration tab or other filterable list views in the portal if applicable.

Problem In the Team Auditing page, article audit entries currently link to the article on the public knowledge base site. Since auditing is done within the Knowledge base portal, there is no direct link to open the article in the authoring portal (Documentation editor), forcing users to navigate there manually. Requested Solution Show two links on each article-related audit entry: Existing link to the article on the public knowledge base site New link to the article in the Knowledge base portal (Documentation editor) Benefits Reviewers can open and act on articles directly from the audit log Reduces context switching during audits Keeps the audit experience self-contained within the portal Use Cases Post-release audits, compliance reviews, investigating article changes and immediately opening the article to verify or correct it.

The audit log should be searchable, or at least filterable to specific articles. While there is the Revision History section at the article level, it doesn't include actions like hiding an article or relocating it.

We would like to track bulk tag deletions as well. Currently, the team audit section only shows individual operations. It would be very helpful to also track bulk operation activities in the team audit section. Thank you.