> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dmly.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Read the workspace audit log

> Browse an append-only trail of high-value actions taken in your workspace, filterable by action and date range.

The audit log is a record of *who did what, when* for a specific set of high-value or destructive actions in your workspace, not a complete history of everything that happens. Each row is written once and never edited. This page is an honest account of what it currently covers, so you know what to trust it for and what to still check elsewhere.

<Note>
  Viewing the audit log needs the **View the audit log** permission (`team.audit_log`). The workspace owner and Admins hold it by default; Members and Viewers don't, though a custom role can grant it to a Member. See [Roles and permissions](/account/roles-and-permissions).
</Note>

## Open the audit log

<Steps>
  <Step title="Open Workspace Settings">
    Workspace Settings is a separate area from the main sidebar, with its own nav: **Settings**, **Team Members**, **Billing**, **Receipts**, and **Security**.
  </Step>

  <Step title="Go to Settings → Audit log">
    **Audit log** is a tab on the **Settings** page, alongside **Business Details**, **Conversation settings**, **Appointment settings**, **Finance settings**, **Notification settings**, **AI Knowledge** and **Custom fields**.
  </Step>
</Steps>

## What's on the page

Each row shows **When**, **Who** (the team member's name, or **System** if no one was signed in when it happened), **Action** (a short code like `contact.delete`), **Summary** (a plain-language sentence of what happened), and **IP** (the address the request came from). The list is paginated, 30 rows at a time.

Selecting a row doesn't open any further detail; the **Summary** column is the full description you get. There's no export or delete control on the page; it's read-only.

## Filtering

<Columns cols={2}>
  <Card title="Action" icon="filter">
    A dropdown of action codes. It's built from the actions that have actually happened in your workspace, so a quiet workspace will show a short list.
  </Card>

  <Card title="Date range" icon="calendar">
    **All time**, **Last 24 hours**, **Last 7 days**, or **Last 30 days**.
  </Card>
</Columns>

## What's actually logged today

This is the part worth reading carefully: the audit log covers three specific groups of actions, not every change made in the workspace.

### Actions taken in the dashboard

| Action code                | What it records                         |
| -------------------------- | --------------------------------------- |
| `contact.delete`           | Deleting a single contact               |
| `contact.bulk_delete`      | Bulk-deleting contacts                  |
| `contact.bulk_add_tag`     | Bulk-adding a tag to contacts           |
| `contact.bulk_remove_tag`  | Bulk-removing a tag from contacts       |
| `contact.bulk_set_stage`   | Bulk-changing contacts' lifecycle stage |
| `offering.services_import` | Importing services from a CSV file      |
| `automation.bulk_delete`   | Bulk-deleting automations               |

These rows come from the dashboard only. The same actions performed through the [REST API](/api-reference/introduction) write no audit row at all, so a contact deleted by a script or an integration leaves nothing here.

### An agency opening your workspace

| Action code          | What it records                                                              |
| -------------------- | ---------------------------------------------------------------------------- |
| `agency.impersonate` | A whitelabel agency signing in to your workspace as its owner, with **Open** |

This one only appears in a workspace an agency manages. See [Client workspaces](/agency/client-workspaces).

<Note>
  The row is written at the moment the agency signs in, and it is the only marker you get. From then on they are acting *as* the owner, so anything else they do while inside is recorded under the owner's name, not theirs. The **Who** on the `agency.impersonate` row itself is the agency's own user, which may be a name you don't otherwise see in your team list.
</Note>

### Writes made by an AI client over MCP

| Action code           | What it records                                                                                                     |
| --------------------- | ------------------------------------------------------------------------------------------------------------------- |
| `mcp.session_started` | An AI client connecting to the workspace, naming the client that connected                                          |
| `mcp.<tool name>`     | One row per write that client makes, for example `mcp.send_message`, `mcp.create_invoice` or `mcp.book_appointment` |

Each of the 20 tools that change something writes its own row, so an AI booking an appointment, tagging a contact or queueing a broadcast all leave a trail. Reads don't: a model looking up a contact or reading a conversation writes nothing, on purpose, because a read tool called several times per reply would bury everything else. Nor does the broadcast preview step, which only works out who a broadcast would reach; the `mcp.submit_broadcast` row is what records the send being queued for approval.

What the **Who** column shows depends on how the client connected. Through a connection someone authorized with their own login, it's that person's name. Through a workspace API key there's nobody signed in, so it reads **System**. The `mcp.` prefix on the action code is the reliable signal that an AI did it, because the **Summary** doesn't always say so. See [the MCP server](/mcp/overview).

<Warning>
  Nothing outside those three groups writes to the audit log. Deleting a single automation, editing a broadcast, changing finance settings, refunding a payment, removing a team member, and most other admin actions don't appear here at all. Don't rely on this page to answer "who changed X" for anything outside the lists above. For message and delivery failures, see [Logs](/troubleshooting/logs) instead, which is a different, unrelated record.
</Warning>

## Retention

Audit log entries are kept for **180 days**, then removed automatically. There's no way to extend that from inside DMLY, and no export button, so if you need to keep a record longer than that, copy what you need out before it ages off.

<Accordion title="Troubleshooting">
  <Accordion title="I can't see the Audit log tab">
    You need the **View the audit log** permission. The workspace owner and Admins have it automatically; a Member needs a custom role that grants it. See [Roles and permissions](/account/roles-and-permissions).
  </Accordion>

  <Accordion title="An action I took isn't showing up">
    Most actions in DMLY don't write an audit row; only the ones listed above do. This isn't a bug; that action simply isn't instrumented.
  </Accordion>

  <Accordion title="An entry I expected to still be there is gone">
    Entries older than 180 days are pruned automatically and can't be recovered.
  </Accordion>
</Accordion>

## Next

<Columns cols={2}>
  <Card title="Roles and permissions" icon="user-shield" href="/account/roles-and-permissions">
    Grant the audit log permission to a custom role.
  </Card>

  <Card title="Team members" icon="users" href="/account/team-members">
    Invite people and set their base role.
  </Card>

  <Card title="Security" icon="shield-halved" href="/account/security">
    Two-factor authentication and other account protections.
  </Card>

  <Card title="Reading the Logs page" icon="clipboard-list" href="/troubleshooting/logs">
    The separate, unrelated record of message and automation delivery events.
  </Card>
</Columns>