Audit Events

Settings → Audit Events records privileged actions across the platform. Recording is automatic — there is no per-resource opt-in and no way for a user to suppress an entry. The page requires the ADMIN authority and is Enterprise Edition.

Finding an event

The screen has a filter sidebar on the left and a results table on the right.

A Clear filters link resets everything, and the page header shows a live Filter by summary of what is active. With no matches the table reads "No audit events match the current filters."

The results table lists Date, Principal, and Event Type. Clicking a row opens the Audit Event Details panel, showing the event type with its timestamp, the Principal, the Event ID, and the event's recorded Data as key/value pairs. When results span multiple pages, Previous / Next page through them.

What an entry contains

Each row in persistent_audit_event carries exactly four fields, plus its data map in persistent_audit_event_data:

• Event ID — the entry's identifier.
• Principal — the acting user's login.
• Event type — the verb, e.g. WORKFLOW_UPDATED, CONNECTION_DELETED. The full set is catalogued below.
• Event date — when it happened.
• Data — a string-to-string map of whatever the emitting site chose to record, typically the affected resource's id and name. Null values are dropped rather than stored.

Anything you want to filter on later has to be in the Data map — that is what Search data searches.

Correlation IDs for bulk operations

A single admin action that fans out into many writes — reassigning every connection in a workspace, for example — would otherwise read as dozens of unrelated entries. When a bulk operation establishes a correlation scope, every audit event raised beneath it picks up the same id and records it under the correlationId data key, so the timeline can be reassembled without relying on timestamps being close together.

The correlation id is carried in a plain thread-local, deliberately not an inheritable one: work handed to another thread does not inherit it, because leaking a correlation id across a recycled pool thread is worse than losing the grouping.

Strict-audit events

Some events are marked strict: if the audit entry cannot be written, the operation itself fails rather than proceeding unrecorded. The events that can remove someone's access are the ones marked this way — CONNECTION_DELETED, CONNECTION_VISIBILITY_CHANGED, CONNECTION_ACCESS_REVOKED, CONNECTION_REASSIGNED, and AI_HUB_CHAT_DELETED. A failed non-strict write is counted on the bytechef_connection_audit_failed / bytechef_ai_hub_audit_failed counters instead of failing the request.

Event types

The dropdown on the page is populated from the events your instance has actually recorded. The full set the platform can emit:

What is not logged

• Secret values. The log records that a credential was created or deleted, by whom, and when — never the secret material.
• Workflow execution data. Execution inputs and outputs live in execution history, so the audit log stays focused on privileged administrative actions rather than data flow.

Retention

Audit entries persist in your operational database. A scheduled job deletes entries older than the retention window:

Retention is instance-wide, not per workspace.