Feature Request

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.

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.

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 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.

In team auditing, "Changed article visibility" should really be split into two logs that are more descriptive: "Hid article" or "Unhid article". Hiding and unhiding articles are two different actions, and sometimes I want to see one and not the other in the list – and furthermore, be able to easily distinguish whether or not "change article visibility" means hidden > visible or visible > hidden.

The Team Auditing log has so much useful information, and we use it as a main reference point for article changes, but the filtering and functionality could use improvement. 1) In addition to filtering by individual user, it's imperative we have the option to filter by KB/workspace. Each person on our team manages multiple workspaces, so if I were to view audit information on my own activity, it would list articles across different workspaces. So there's no way for me to isolate audit activity to just one workspace. 2) As part of the log information in grey (user, publish date, and language), it should also list the workspace the audit entry belongs to. This would help me visually isolate entries for one workspace, and would be especially helpful if the workspace filtering functionality needs more time to be implemented. In addition, we have some generic articles that may have the same title across our different product's workspaces (e.g. "Getting Started" or "FAQ") so identifying the workspace it belongs through within the entry is necessary to know which article it even references. Thank you! :)

In the Team Auditing section, the timestamp is visible when hovering over the date. However, the exported CSV currently does not include the time. Including the timestamp in the export would help customers obtain more precise details for their records.