Admin activity

Click your avatar at the bottom of the sidebar to open the user menu, choose Organization Settings, then the Admin activity tab, 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: publishing or unpublishing its AI Storefront (AI Storefront published or unpublished), rotating its public key, adding or removing an authorized domain, the agent onboarding set to answer on it (Default agent changed, on older entries only: onboarding no longer puts an agent live, and Go live is recorded as Agent went live), changing its languages or default language, its branding, its web search/fetch domains, or whether fetched pages render JavaScript; switching automatic starter generation on or off (Automatic starter generation changed), page-view counting on or off (Page view counting changed), or automatic reading and its threshold (Automatic page reading changed); launching a web-tag performance run.
• Agents and configuration versions: creating, editing, or deleting an agent; saving a configuration version; renaming a version (Agent version renamed, also recorded when you name it in the Go live confirmation); putting an agent live (Agent went live, also recorded when the delete dialog puts the replacement live) or taking it offline (Agent taken offline); changing a version's status through the API.
• 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; going live or taking offline (the Switch it off instead button in the delete dialog records the same taken-offline entry as Take offline); restoring an earlier version; minting or revoking a storefront preview link.
• Starter questions: creating, editing, duplicating, deleting, reordering, or turning one on or off. An edit entry records whether the question is written by you, AI-generated or AI-generated and edited.
• Pages: starting a sitemap import (Sitemap import requested), adding pages (Site pages added), reading them or reading them again (Site pages read requested), reading every Not read page (All Not read pages requested to be read, then Reading of all Not read pages ended, attributed to System), removing them (Site pages removed), asking for questions from them (Starter questions requested from pages), adding an exclusion rule (Page exclusion added) and removing exclusions (Page exclusion removed). Each entry targets the site and carries counts only, such as how many pages were submitted, accepted or skipped. It never carries an address, a page's text or a question. The questions a generation writes get no entry of their own: the request, or the automation setting, is the recorded decision. When automatic generation starts a run, the Starter questions requested from pages entry is attributed to System. A run of automatic reading that reads at least one page writes Pages read automatically, also attributed to System, with how many pages it selected and queued. The pages an import or the traffic run finds get no entry of their own, and the import onboarding starts writes none.
• 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), from the MCP server or from a scheduled system job carries no origin, since none of them comes from a browser.

The Source column says which of the four it came through: dashboard, api, mcp or system. An entry with source mcp is a change an AI assistant made through a connected MCP client. It is attributed to the member who authorized that client, and it is recorded under the same action as the dashboard's. A write the MCP server refuses for lack of a permission is recorded as a blocked attempt too, with source mcp. There is no Source filter; the column is sortable.

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 Admin activity 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. The log opens newest first.

• 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; Admin activity: 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.

SortCopy Anchor Link

Three columns sort: Date, Action and Source. Click a header to sort by it, click again to reverse the direction. The log opens newest first, and a click on Date reverses it. From another column, a click on Date sorts newest first. Action and Source sort ascending on the first click. Sorting applies to the whole filtered log, not just the rows on screen, and takes you back to the first page.

• Action sorts on the action's internal key (member.removed), not on the label shown, so actions of the same area sit together.
• Source sorts in the order dashboard, api, system, mcp, not alphabetically.
• Site, Actor and Target don't sort. To narrow the log to one site or one actor, use the filters instead.

Page through the logCopy Anchor Link

The table shows 50 entries per page. Previous and Next, under the table, move one page at a time; there are no page numbers. The range next to them reads 1–50 of 1,234. Past 10,000 matching entries the count stops and the range reads 1–50 of more than 10,000.

If a page can't load at all, the table shows This list couldn't load with a Try again button.

Click a row for the full entryCopy Anchor Link

Click anywhere on a row to open a detail panel from the right, titled Activity entry, 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 searchable dropdown of everyone recorded as an actor in your log, plus System and All actors. It lists members who have since left and API keys since revoked, by the name or email the log last recorded for them. With the API keys: View (or Edit) permission, a key shows under its current name. Two actors with the same name show their reference in parentheses so you can tell them apart. The list stops at 500 actors and says so in its heading
• 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. Admin activity 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. When nothing matches, the table reads No activity matches these filters. Changing a filter takes you back to the first page.

Share or reset a viewCopy Anchor Link

The filters, the sort and the page you're on are all in the page address. Reload the page and you land on the same view; send the address to a colleague in your organization who holds the same permission and they see the same entries. Reset, at the end of the filter bar, clears every filter and the sort and returns to the newest entries. It shows only when a filter or a sort other than the default is set.

An address whose page can no longer be used (the link was edited, or the entries it pointed to are gone) opens the first page of the same filters and sort instead of an error.

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, newest first, whatever sort the table shows. 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.