Skip to main content
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.
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.

​
Open the audit log

1

Open Workspace Settings

Workspace Settings is a separate area from the main sidebar, with its own nav: Settings, Team Members, Billing, Receipts, and Security.
2

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.

​
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

Action

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.

Date range

All time, Last 24 hours, Last 7 days, or Last 30 days.

​
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

These rows come from the dashboard only. The same actions performed through the REST API write no audit row at all, so a contact deleted by a script or an integration leaves nothing here.

​
An agency opening your workspace

This one only appears in a workspace an agency manages. See Client workspaces.
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.

​
Writes made by an AI client over MCP

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.
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 instead, which is a different, unrelated record.

​
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.
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.
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.
Entries older than 180 days are pruned automatically and can’t be recovered.

​
Next

Roles and permissions

Grant the audit log permission to a custom role.

Team members

Invite people and set their base role.

Security

Two-factor authentication and other account protections.

Reading the Logs page

The separate, unrelated record of message and automation delivery events.