Activity

Every logged change in the store is one Activity row.

Each row records four things: a type, a description, the admin or customer behind it, and the product, order or collab it touched.

Insights → Activity reads that one table. So does each record's own timeline — it is the same rows, filtered to that record. There is no separate per-record history that could fall out of step with the store-wide one.

The log lives at:

Insights → Activity
/admin/activity

It requires the activity:view permission.

What gets written

Four operations write an activity row:

• Create
• Update
• Delete
• Duplicate

They write it through the shared layer that every record edit passes through, rather than each screen remembering to log for itself. That is why coverage is broad and consistent — a module does not opt in to being logged.

The changed fields are stored on the row in a metadata field, so an update row can tell you what actually changed, not merely that something did.

The default view

The feed opens on the last 30 days and loads 100 items, with pinned rows on top.

window     last 30 days
page       100 items
ordering   pinned rows first

Pinning is how you keep an investigation in front of you. A row you pin stays at the top of the feed while you filter around it.

Filters

You narrow the feed four ways:

1. Module — orders, products, refunds, disputes, shipping rates, API keys, webhooks, settings and the rest
2. Activity type within a module
3. Date range
4. The specific admin, customer, product, order or collab involved

The fourth is the one that turns the log from a stream into an answer. Filtering to a single order shows every change anyone made to it, in order, regardless of which screen they made it from.

Who did it

The actor on a row is the admin or customer behind the change.

There is one exception. Actions the AI assistant performed after you approved them are stamped with an ai actor and read as "by AI" rather than as the approving admin.

That is deliberate. You approved the action, but you did not compose it, and a log that credited you with the assistant's work would misrepresent what happened when someone reads it back six months later.

Why a retry cannot double-log

Some writes arrive through background delivery that guarantees an event arrives at least once — which means it can arrive more than once.

Those writes carry a deduplication key. A retried background job therefore cannot log the same change twice.

Without that, the log would over-report exactly the changes that had trouble, which is the worst possible place for it to be wrong.

Export

The visible feed exports to CSV.

"Visible" is the operative word: the export follows your filters, so narrowing to one module and one date range before exporting gives you that slice rather than the whole table.

Using the log

Reach for the log when a number moved and you want to know why, or when a record is in a state nobody remembers putting it in.

Start from the record rather than the store-wide feed when you already know which record is involved — its own timeline is the same data, pre-filtered.

Use the store-wide feed with a module filter when you suspect a pattern rather than a single incident.

The log answers "who changed this, and what did they change it from?" — if your question is "what is this number made of", that is the analytics page, not this one.

Related