Workspace
Activity log
Trace recorded content, publication and administration actions and use event details to investigate changes.
What the log records
Activity log presents audit events written by the CMS as your team changes the workspace. Examples include content creation and saving, publication decisions, scheduling, API-key administration and people-management actions. It gives administrators a timeline of recorded changes, with structured details where the operation supplies them.
The log is scoped to the current site and requires the audit permission, which is administrator-only. It is not a visitor analytics dashboard, a count of page views or a guarantee that every browser action or authentication event is logged. A missing event does not prove that someone never opened a screen.
Sources: Audit filtering and pagination; Audit permission; Content audit events; People audit events.
Find and inspect an event
- Open Activity log from the Workspace group, or choose View activity log in Settings.
- Enter an action keyword in Search actions and choose Search. Search matches recorded actions; it is not a universal search across every value in event-detail JSON.
- Use Previous page and Next page to move through results. The total and page count refer to the filtered results. Select Refresh to retrieve recent events.
- Expand Event details beneath a row to inspect its JSON when details are present. Read IDs, versions, reasons or outcomes alongside the action and timestamp.
- Where an event references a resource, use Open content to inspect that record. Compare its Revision history or publishing state with the event you are investigating.
The heading converts action separators into readable words. The details preserve structured values, which are especially useful when two records have similar titles or when newer edits exist. The screen does not provide a separate author/date-range filter or an undo-event action. If a support request needs a precise event, include the action, time and relevant resource or revision ID.
Sources: Activity log interface; Audit filtering and pagination.
Investigate an unexpected page change
Suppose the homepage looks different after a team member publishes a shared header. Locate the publication event and open its referenced content. Inspect the header’s published revision and compare it with its working revision. The changed page may be a consumer of the shared header rather than the resource that was directly edited. The Templates and Shared sections guides explain this relationship.
For an article that did not change when expected, compare the schedule or review’s revision ID with the resource’s published revision. A newer working draft does not replace the revision pinned to an earlier approval or schedule. Review the relevant queue’s error or state as well as the audit record before deciding what to publish next.
Sources: Content audit events; Activity log interface.
Keep investigation separate from recovery
An audit entry is evidence of an operation, not a content snapshot you can restore. Use Revision history to restore content into a working revision, then review and publish it. Use a verified database-and-media backup for whole-installation disaster recovery. The workspace JSON content export is not a complete backup and does not replace the database containing audit history.
The Activity log interface has no dedicated bulk-download or retention-settings form. Operators who need longer-term audit retention must manage database backups and any external retention policy at the deployment level. Share only the details needed for support: event payloads may identify people, records or unpublished work.
Sources: Activity log interface; Workspace export payload; Backup and recovery runbook.