> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nexalytica.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Review Your Organisation's Audit Log in Nexalytica
> Read, filter, and investigate a tamper-proof record of every create, update, and delete action taken across your Nexalytica organisation.
The **Audit Log** is Nexalytica's permanent, tamper-proof record of every change made across your organisation. Every create, update, and delete is captured automatically the moment it happens — no setup required. You cannot edit or erase entries, which makes the log a reliable source of truth for security audits, access reviews, incident investigations, and regulatory obligations. Navigate to **Settings → Audit Log** to start reading.
***
## What the audit log records
The Audit Log is **one unified feed** that merges two kinds of events into a single table:
* **Changes** — someone created, updated, or deleted a record.
* **Admin Access** — an org admin used the audited admin view to look at members' personal resources (the implicit-access path described under Privacy).
Every row carries a small **source badge** telling you which kind it is. The table has five columns — **Time, Actor, Action, Target, Detail**:
| Row kind | What Detail shows |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Change** | A field-level "before and after" diff: the previous value struck through, the new value beside it, up to three fields with a "+N more" note when more changed. Newly created records show a dash (no prior state to compare). Actions are colour-coded — 🟢 green **Created**, 🔵 blue **Updated**, 🔴 red **Deleted**. |
| **Admin access** | A summary of whose resources were viewed ("owners: N"), the session's device and IP context, and the first few resource names accessed ("+N more"). |
The **Actor** column shows the person's email, or **system** for automated changes.
### Resource types
The **Resource** filter uses friendly names for the kind of record involved. Which options appear depends on the row kind:
| For **Changes** | For **Admin Access** |
| ------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| User, Organisation, Membership, Invitation, Join Request, Email Verification, Session | Dashboard, Data Source, Data Store, Vector Store, Folder, File, Chat |
***
## Filtering the log
Use the controls at the top of the log to narrow the entries shown. Filters combine, so you can scope to a specific event type, user, department, resource, action, and date range simultaneously.
| Control | Options |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Type** filter | **All Activity**, **Changes** only, or **Admin Access** only — the master switch that splits the two feeds |
| **User** filter | Narrows to activity by a specific person |
| **Department** filter | Narrows to activity by the members of a specific department |
| **Resource** filter | Narrows by record type (options depend on the selected Type — see above) |
| **Action** filter | For **Changes** only — All / Created / Updated / Deleted |
| **From** / **To** date fields | Limit the feed to a date range (interpreted as whole days) |
| **Clear all** button | Resets every filter back to its default |
To investigate a specific incident, set a narrow **From/To** window and start with the **Type** filter. Add a **User** or **Department** filter to focus on the people involved.
***
## Navigating pages
Use the pagination controls at the bottom of the table to move through the full log.
| Control | What it does |
| --------------------- | ------------------------------------------------------- |
| **← Previous** arrow | Moves to the preceding page |
| **→ Next** arrow | Moves to the following page |
| Footer range | Tells you which entries are visible and the total count |
| Page number indicator | Shows your current position in the full log |
***
## Permissions
| Role | What they can do |
| ------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **All org members** | Read the full audit log (resource, action, changes, user, date) |
| **Org Admins** | All of the above, plus view admin-view invocation entries (Session rows created when elevated privileges were used) |
The audit log is **append-only**. Entries can be filtered and read from this screen, but they can never be altered or deleted — by anyone, including org owners. This immutability is what makes the log credible evidence for external audits and regulatory inspections.
***
## Using the audit log for compliance
The audit log is purpose-built to support the scenarios that matter most for governance and security teams.
Demonstrate a complete chain of custody for configuration changes. Every action is timestamped and attributed to a specific user or the system.
Confirm which users accessed or modified sensitive records during a given period. Filter by Resource → User and set a date window to pull a clean report.
Reconstruct the sequence of events leading to an incident. Combine date, resource, and action filters to isolate the relevant entries and share them with your security team.
Meet requirements under GDPR, SOC 2, ISO 27001, and similar frameworks that mandate a tamper-proof change history. The append-only log satisfies the immutability requirement out of the box.