Using the audit UI

The audit UI shows the events described in Data model as a searchable list, with a dedicated detail page per event. It is served by the Audit module unless deployed headless.

Change views

The current audit frontend opens a change stream with Operations, Objects and Executions views. Operations groups writes by connector call; Objects groups affected target objects and shows their related identities; Executions groups matching changes by chain. Switching view carries the search criteria and runs a fresh query. Results support paging; object searches can sort by name or time.

The grouped chain list remains available at chains, and chain details at chains/<chainId>, below the UI base path. Older separately packaged audit frontends may open this list directly. The backend module does not choose or unpack a frontend version; webroot_dir must contain the installed UI.

Event list

The event list shows one card per event, newest first: source type and name, status, initiator, and when the event started and ended. Selecting a card opens that event's detail page.

Search

A search panel on the left of the list controls which events are shown:

• Time window — Last 24 hours (the default), Last 7 days, Last 30 days, or All.
• Source — restrict to Flow, Schedule, API, or Manual events.
• Status — restrict to In progress, Succeeded, Failed, or Partially succeeded.

Search criteria are part of the page's URL, so a specific search can be bookmarked or shared. Changing any criterion re-queries the event list rather than filtering what is already on screen — narrowing the time window on a busy system reduces load time, since the list has no separate paging.

Event detail

An event's detail page shows its source, status, initiator, and start and end time, followed by its change packages in chronological order, each numbered.

For each change package:

• Package type — a readable label such as "Created user" when one is defined for that package type, or its raw technical code otherwise.
• Identity — the display name (when known) and the raw identity reference the package concerns.
• Time — when the package's changes occurred.
• Target connection — which connected system and destination the changes were written to.
• Affected objects — every object touched by the package's changes, which is not always the same as the package's identity.

Below that, a table lists the package's individual changes: field, value before, value after, and result. Expanding a change reveals the raw source event it was derived from, as formatted JSON — useful when the readable fields above don't fully answer "what actually happened here."