Audit log

Click your avatar at the bottom of the sidebar to open the user menu, choose Organization Settings, then Audit log, or go directly to /dashboard/settings/audit-logs. This page lists admin actions taken across your organization: who did what, when, and what it targeted.

What it recordsCopy Anchor Link

Each entry logs one action, with who did it (or System for a scheduled job), when, and what it targeted. Coverage spans essentially every configuration change your team can make:

• Access, roles, and your organization profile: inviting a member, removing one, or changing their role; revoking a pending invitation; creating or revoking an API key; creating, editing, or deleting a custom role; renaming your organization or updating its profile.
• Sites: creating, editing, or deleting a site, and everything touching its security perimeter: turning public access on or off, rotating its public key, adding or removing an allowed origin, choosing its default agent, changing its languages or default language, its branding, its web search/fetch domains, or whether fetched pages render JavaScript; launching a web-tag performance run.
• Agents and configuration versions: creating, editing, or deleting an agent; creating a new configuration version; promoting, archiving, or otherwise changing a version's status.
• Connectors: adding, editing, or disabling one, and changing which of its tools are enabled.
• Instruction blocks: creating, revising, editing, or disabling one.
• Engagement widgets: creating, renaming, duplicating, or deleting a widget; turning it on or off; publishing a draft or restoring an earlier version; minting or revoking a storefront preview link.
• Starter questions: creating, editing, duplicating, deleting, reordering, or turning one on or off.
• Evaluation: launching an evaluation run, and creating or editing a custom scenario or subcategory.
• Conversations: deleting a conversation from the dashboard (a shopper erasing their own conversation is a separate, unattributed path and isn't logged here), and asking for one conversation to be labeled now with Label now (Labeling requested for a conversation, targeting that conversation, with how many conversations were selected and queued). Entries written before Label now moved to each conversation target the organization instead, and read Conversation labeling requested. The hourly labeling pass has no actor and writes no entry.
• System retention: a scheduled data-retention purge, attributed to System, one summary entry per purge run rather than one row per deleted record.

Blocked attempts show up tooCopy Anchor Link

An entry isn't only written when an action succeeds. If a member tries something their role doesn't allow (attempting to delete a site without Sites: Edit, say), that attempt is recorded as well, naming the action they tried and what it targeted. The two are kept distinct behind the scenes (a refused attempt is never mixed up with a genuine mistake, like a rejected form): a row for a blocked attempt looks like any other on the table itself, but open its detail panel (see below) and its Outcome field reads Denied. Treat a repeated attempt at something a member shouldn't be able to do as worth a closer look either way.

A validation error, a no-op, or a save that simply didn't change anything isn't recorded. Only an action refused by a permission check is.

Where an action came fromCopy Anchor Link

An entry created from the dashboard now also captures the IP address and browser it came from. Neither has its own column on this page. Open the row's detail panel (see below) or the CSV export (see below) to see them. An entry from the public API (an API key) or from a scheduled system job carries no origin, since neither one comes from a browser.

How long entries are keptCopy Anchor Link

Entries don't stay forever. Each organization has a retention window, and a scheduled job purges entries older than that window every day. By default, that window is 365 days; iAdvize can set a longer or shorter window for your organization directly, but there's no setting for it in the dashboard; it isn't something you configure yourself.

The purge run itself is logged too: if a run for your organization actually deletes anything, it writes one Audit log purged (retention) entry, attributed to System, recording how many rows were removed. A run that finds nothing past the window for your organization writes nothing.

Read-only, alwaysCopy Anchor Link

There's nothing to edit or delete here, for anyone, not even the person whose action a row records. Entries accumulate (until retention catches up with the oldest ones); none of them can be corrected or removed from the dashboard.

The tableCopy Anchor Link

Columns run Date, Site, Actor, Action, Target, Source. Every one of them is sortable: click a column header to sort by it, click again to reverse the direction. Sorting applies to the full filtered result set, not just the rows currently on screen.

• Site sits right after Date and shows the resolved site name for a site-scoped action, or an em dash (—) for an organization-level action (inviting a member, changing a role) that isn't tied to any one site.
• Actor shows the name or email of whoever did it. For an action taken through the public API, it shows the API key's current name rather than its raw identifier, but only if you also hold the API keys: View (or Edit) permission; Audit log: View alone doesn't include it. Without that second permission you see the key's raw stored reference instead. Key no longer exists is reserved for a key that's genuinely been looked up and confirmed permanently revoked; it's never shown just because you lack permission to resolve names.
• Action shows a plain-language label (e.g. "Member removed") instead of the raw registry code.
• Target shows the actual thing the action touched (a site's name, an agent's name) when one was captured, falling back to the generic type (e.g. "site") when it wasn't.

Click a row for the full entryCopy Anchor Link

Click anywhere on a row to open a detail panel from the right, showing every field that entry carries, including the ones that don't have their own column: Outcome (Succeeded/Denied), IP address, User agent, and Metadata. Almost everything that used to require downloading the export to see is one click away instead. The one exception is the WorkOS sync status, kept out of the panel on purpose (see below).

The panel lists, in order: Date, Site, Actor (with the actor type underneath), Action (with the raw action key underneath), Target (with its type and id underneath), Source, Outcome, IP address, User agent, and Metadata (or an em dash if none was recorded). It never shows whether the entry synced to WorkOS: that field exists only in the CSV export, and only for iAdvize operations use (see Export to CSV).

Filter and searchCopy Anchor Link

• Site: a searchable, accent-insensitive dropdown listing every site in your organization plus All sites; type to narrow it down the same way the Action filter next to it does
• Action: a searchable dropdown listing every action in the registry, grouped by sensitivity (High / Medium / Low), each shown by its plain-language label; type to narrow it down instead of guessing the raw code
• Actor: a substring match against the name or email of whoever did it
• From / To: a date-range picker with quick presets (Today, Yesterday, Last 7 days, Last 30 days, This month, Last month, Year to date, Last year, Last 12 months) and a two-month calendar for a custom range. The audit log keeps entries for its own retention window (365 days by default) and shows no notice when a range reaches past it, so Last year and Last 12 months list only the entries still retained

Filters combine: narrowing by site and a date range together shows only entries matching both.

Export to CSVCopy Anchor Link

Export CSV, top-right of the page, downloads every entry matching the current filters (not just the current page) as a CSV file. A single export caps at 5,000 rows; narrow your filters (a date range is the fastest way) if you have more than that to pull. If your filters still match more than 5,000 rows, the file itself ends with a trailing line saying the export was truncated, so a partial pull is never silent.

The export carries more than the table (or the row detail panel) shows: alongside the fields already exported, it includes the target's resolved label, the outcome, the originating IP address and browser (for a dashboard-originated entry), and the entry's raw metadata as JSON.

It also carries one field found nowhere else on this page: whether the entry has synced to iAdvize's own WorkOS Audit Logs mirror. This is an internal operations field, not a merchant-facing status: no organization is currently entitled to that mirror, so today it reads No on every row of every export. It's deliberately absent from the table and the detail panel for exactly that reason: a status that can only ever read one value has nothing to tell you there.

What this doesn't cover yetCopy Anchor Link

A few things stay off this page on purpose, because they either aren't organization configuration or aren't a meaningful admin action:

• Personal account settings: your own profile, password, two-factor setup, notification preferences, and signing out your own sessions. These affect only your account, not your organization, so they're deliberately out of scope here (see Account settings).
• Draft edits that haven't been published: saving a widget draft, for instance, happens repeatedly while you work and is invisible to shoppers until you publish; only the publish (and restoring an earlier version) is logged.
• Resending an invitation email: the invitee, their role, and the invitation itself don't change, so resending isn't logged (the original invite and any later revocation are).
• Read-only checks: anything that only reads data back, like a precondition check or a storefront-preview probe, doesn't write an entry.
• Automatic background refreshes with no one behind them: a connector's tool catalog refreshing itself from the live MCP server, for example.
• Shopper-side activity: feedback a shopper leaves on a message, or interaction events your storefront reports, is shopper telemetry, not an admin action.
• Early onboarding steps: before a site actually goes live, the setup screens you fill in (business description, review steps) and status polling aren't logged; the site itself being created is.

Outside of those, an admin action taken in your organization's back office should show up here, including a blocked attempt at one.