Skip to content

Audit events

Case Tables records what was done to tables, domains, and jobs. The events land in the shared audit log, so changes to a schema can be traced after the fact.

Where the events go

Each operation writes one structured entry to the lurana log channel, which is collected and stored with the rest of the audit data. Read them in Audit log → Explorer from the Audit log section, filtering by the case-tables. prefix.

Each entry carries:

Field Content
event_type case-tables.<entity>.<action>
entity_type CaseTable, CaseTableJob, or CaseTableDomain
entity_uid The table, job, or domain affected
user_uid Who did it, or system when no user was involved
timestamp When it happened
payload Context: names, statuses, severity, error summary

Events describe operations. They do not contain the rows of a table.

Table events

Event Recorded when Context
case-tables.table.created A table is created Name, display name, domain, classification
case-tables.table.schema_changed The schema is edited Table name and a change summary
case-tables.table.status_changed The table changes state From-status and to-status
case-tables.table.deleted A table is deleted Table name

table.status_changed is the one to watch during a migration: it records every transition of the lifecycle, so a plan that failed and was retried leaves a trail.

Job events

Event Recorded when Context
case-tables.job.created A job is created by a publish or bulk operation Job, table, type, severity
case-tables.job.queued The job is dispatched for execution Job and table
case-tables.job.completed Execution succeeded Duration
case-tables.job.failed Execution failed Error message
case-tables.job.cancelled A pending job is cancelled Job and table
case-tables.job.approved A plan that required approval is approved Severity and who approved it

Domain events

Event Recorded when Context
case-tables.domain.created A domain is created Name and prefix
case-tables.domain.deleted A domain is deleted Name

Reading a sequence

A typical publish leaves four entries for the same table:

case-tables.table.status_changed   ACTIVE → PENDING
case-tables.job.created            severity, table
case-tables.table.status_changed   PENDING → ACTIVE_PENDING
case-tables.job.queued             job dispatched
case-tables.job.completed          duration
case-tables.table.status_changed   SYNCING → ACTIVE

A failure ends the same sequence with case-tables.job.failed and a status_changed into ERROR, which is how you match a failed table with the plan that broke it.

Permissions

Reading these events requires the audit permissions, not the Case Tables ones. See Permission model for the audit-log permissions and Permission reference for the codes.