Improve clarity in Team Auditing logs for notification channel updates and article visibility changes
backlog
V
Vijay Sakthivel
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.
Log In
D
D360 Product Management
Merged in a post:
Granular Audit Logging for KB Widget Configuration Current behavior
D
Dusk blue Perch
Audit logs for the KB widget currently classify all changes into three broad activities: Created, Updated, and Deleted KB widget settings. This provides no visibility into the specific nature of a change, making it difficult to trace the cause when a live widget instance behaves unexpectedly.
Requested behavior:
We would like audit logs to capture granular, change-specific entries whenever any of the following configurations are modified:
Custom CSS changes
Custom JavaScript changes
URL mapping (add, edit, delete)
JWT token regeneration
JWT enable/disable
Widget rename
Content access changes
Each log entry should capture who made the change and when.
Additional ask: version history and rollback for CSS/JS
For Custom CSS and Custom JavaScript specifically, we would like the ability to view previous versions and roll back to a known-good state, similar to version control. These are the highest-risk configuration areas since even a small unintended edit can break a live widget with no easy way to detect or reverse the change.
If full diff/version control is not feasible, a minimum viable alternative would be retaining a "last known good" snapshot with rollback support.
Why this matters:
We recently encountered an incident where deployed custom CSS was found to be missing several rules compared to a local backup, which broke AI search result rendering on the live widget. There was no way to trace when or how the change occurred through the Doc360 portal; the issue was only caught by manually comparing against a local backup. Granular, diffable audit logging would have significantly reduced the time and effort needed to identify and resolve this.
Auto-save behavior
We also considered whether the KB widget's auto-save behavior (changes are saved automatically when switching between configuration tabs) needs a separate fix, such as a confirmation dialog or a save button per tab. A toast confirmation already exists today, but offers no way to revert once changes are saved. A save button already exists per tab as well; however, for the Custom CSS and Custom JS tabs specifically, even a single mistyped character can break the code before a user realizes it. Rather than requesting a separate save-flow change, we believe a git-like level of detail in the audit log (as requested above) would directly resolve this concern, since it would let us see and revert exactly what changed.
D
D360 Product Management
Merged in a post:
Include events captured in team auditing as a part of the events filter
Uppili Srinivasan
Currently the review reminder updated events in the general settings are not included in the team auditing filter even though it is captured in team auditing. It would be great if all the events captured in the team auditing are included as a part of the filter.
Uppili Srinivasan
+ Keppel green Cattle
D
D360 Product Management
Merged in a post:
Team auditing – display article workspace in logs
E
Expected Condor
Please improve the audit log so that it displays which workspace the article belongs to.
We have over 10 products at our company, and I'm only responsible for 2. So I want to be able to quickly scan the audit log and/or filter by workspace to only view entries for specific workspaces.
K
Kavya
Hi Expected Condor,
Thank you for sharing this.
We’ll merge this request with the existing audit log improvements that are already being tracked, particularly around enhancing filtering and contextual visibility (e.g., workspace-level details).
We’ll consider this use case as part of that broader enhancement and share updates as it progresses.
D
D360 Product Management
updated the status to
backlog
K
Kavya
Hi Expected Condor ,Vijay Sakthivel,
Thank you for sharing this detailed feedback.
We understand the need for more descriptive and granular audit logs, especially for actions like notification channel updates and article visibility changes, where the current logs can be ambiguous.
We’ll consider this as an improvement and review it further based on feasibility and scope. Once it is picked up for implementation, we’ll be sure to keep you informed.
E
Expected Condor
Same issue goes for renaming articles. The entry will say "Updated article title [new name]" but have no mention of the original title.
A better entry would read "Updated article title [old name] to [new name]"
V
Vijay Sakthivel
Raised on behalf of +Expected Condor