What an admin audit trail should record

Sooner or later a customer writes in: "My plan changed and I did not change it." Without an audit trail, you guess. With a good one, you search, find the change, and answer in a minute.

The fields that matter

Who. The person or system that made the change. Not "admin". The actual operator.
When. A timestamp in UTC.
Where. Which product, and which record type and id. product-two / users / usr_8f2.
What. The named action, like extend_access, not "updated row".
Before and after. The exact values that changed. This is the field people skip and the one that answers the question.

Why named actions beat raw edits

If admins can edit any column, your log fills with field changes that nobody can interpret later. Named actions carry intent. grant_credits with a before and after of 40 and 65 tells the whole story.

Keep it where you can search it

An audit log you cannot filter by product, person, action, and date is a log nobody reads. Make it exportable too, as CSV or JSON, so a compliance question or a refund dispute is one download.

Write it on both sides

If your admin tool calls into your product to make a change, record the change in both places: in the admin tool, and in your product's own table. If either side is ever questioned, the other one agrees.

How LopeBase does it

Every change in LopeBase is a named action with a confirm step. Each one writes an audit event with the operator, product, record, time, and before and after, and the admin adapter in your product writes its own row too. The feed filters by product, person, action, and date, and exports as CSV or JSON. See it in the tour.