Audit logs provide functionality to trace actions taken by any persona. They summarise all actions taken by these personas in one place.

Benefits — Leena AI admins in the enterprise can use this for auditing of actions or for performing RCA on any production incident.

Audit Logs has two surfaces: the Explore view (described below) where admins query events that have already been captured, and the Filter Management view in Settings where admins control which events get captured in the first place. If a module's logging is turned off in Filter Management, no events will appear in the Explore view for that module — see Configuring which events get captured at the end of this page.

Click on "Start from new" to create a filter for audit logs.

1. Select the product module you would like to see the audit logs of from the Component ID dropdown.

2. Upon selecting a specific product module, the relevant details for further filtering would be shown below, such as event type, status, start date, end date, priority etc.

   

3. Clicking "Apply" on the filters tab would show the relevant audit logs from the search in the form of a table, with the following columns:

   1. Event Type — Name of the event/activity. A flag icon is shown next to the name if the event has been flagged.

   2. Submodule name — The submodule the event originated from (shown only when the event has a submodule).

   3. Priority — Priority defined by the user/system (if available).

   4. Action User — User who took the action.

   5. Target User — User towards whom the action was directed.

   6. Status — Whether the event action was successful or unsuccessful.

   7. Date — Datetime when the action was executed.

   8. Actions — Kebab menu with View event and Flag event / Unflag event options.

      

4. Clicking on an event opens a detail drawer that shows the full context of the action:

   • Event metadata — Event ID, ingested date and time, component module.
   • Event details — Submodule name, event type, activity description, priority, status.
   • Action user — User type (Dashboard / Bot / System), name, email, and the IP address of the device the action was performed from.
   • Target user (if applicable) — User type, name, email, and current account status (Active / Terminated).
   • Flagging info (if flagged) — Who flagged the event.
   • View update — A link that redirects to the configuration page affected by the action, where applicable.
   • Other Details — A collapsible accordion holding any additional module-specific metadata.

   

5. The details of the action can be exported as a CSV by clicking "Export Event".

Flagging Logs

Admins can flag events for further review by clicking "Flag Event" on an event detail drawer, or via the kebab menu on the table row. Flagging serves as a means to come back to an event later. The action user is also identified that one of their actions has been flagged.

Bulk Actions

An admin can select multiple event logs and Flag or Export them in bulk using the "Flag Selected" and "Export Selected" options that appear in the header when one or more rows are selected.

Additionally, the admin can download the entire filtered audit log set by clicking the three-dots icon on the top-right of the page and choosing "Export Log".

Saved Filters

Filter combinations that admins use repeatedly can be saved and re-applied later, which is useful for recurring compliance reviews (for example, a monthly KM access audit or a quarterly RBAC review).

• After applying a set of filters, click Save filter, give the filter a name and an optional description, and save.
• Saved filters can be opened from the Saved filters dialog, where they can be applied, edited, or deleted.
• Saved filters are stored per dashboard user.

Configuring which events get captured (Filter Management)

The Explore view shows events that have already been captured. What gets captured is controlled separately, from the Filter Management page at Settings → Dashboard settings → Audit Logs.

Each product module that emits audit events appears here as its own card, with:

• Component ID — the short identifier used to scope events in the Explore view (for example, CMS, KMS, SET, ONBOARDING).
• Last updated — the date the capture configuration was last saved.
• Enable logging toggle — turns capture on or off for that module independently of the others.

Clicking a card opens its detail page, where the admin can pick which specific activities to log and apply additional capture criteria.

Modules that emit audit logs

Case Management

Captures configuration changes to the Helpdesk admin setup. The actor's IP address, user agent, and a redirection link to the affected configuration page are recorded automatically with every event.

All above events are emitted at Medium priority.

Knowledge Management

Captures the article lifecycle, connector activity, and KM-level setting changes.

Article lifecycle

Connectors and sync

KM settings

Global Settings

Captures the dashboard-user lifecycle and access events.

Onboarding

Captures the candidate journey, form activity, task execution, and onboarding configuration changes. The component ID resolves to either ONBOARDING or OFFBOARDING based on the bot's onboarding setting, so this may appear as two separate cards in Filter Management depending on the tenant configuration.

Candidate lifecycle

Forms

Tasks and triggers

Configuration

The activity list under each module is fetched dynamically when the configuration page is opened, so newly added platform events become selectable automatically — no manual refresh of Filter Management is required.

Additional criteria to be recorded

Once a module is enabled, the Additional criteria to be recorded for the above events panel lets admins fine-tune capture behaviour. Each criterion is opt-in. Leaving a criterion unchecked means "no constraint applied" — for example, leaving Priority unchecked means events of all priorities are captured.

• Priority — Captures only events at or above the selected level (Critical, High, Medium, Low). Useful for high-volume modules where only sensitive changes need to be reviewed.
• Logging period — A start and end date that bounds when capture is active. Outside this window, no events are recorded for the module. Useful for time-boxed audits or pilot phases.
• Activity description — Captures a human-readable description of the action alongside each event. Each module decides what it puts here. Recommended to keep this on so reviewers do not need to interpret raw event-type codes.
• Status — Captures only events with the chosen outcome (Success, Failed, In-progress). A common pattern is to enable this with "Failed" selected when troubleshooting a specific incident.
• IP address — Captures the IP address of the device from which the action originated. Recommended for any module used for security-sensitive operations (Global Settings especially).
• Automatically expires after — Sets the retention period for captured logs. Configured as a numeric value plus a duration unit (Days, Weeks, Months, Years). The maximum supported retention is 5 years.

By default, Activity description and IP address are turned on, giving compliance reviewers the minimum context needed to reconstruct who did what. The remaining criteria should be turned on only when the admin needs to narrow what gets captured or apply a retention policy.