Audit Trail
The audit trail provides a change history for records in Brother POS. Every modification to key records is tracked with a snapshot of the record's state before and after the change, and who made the change. This gives you a complete history of how your data has evolved over time.
How the Audit Trail Works
When a tracked record is created, updated, or deleted:
- The audit trail system creates a version snapshot.
- The version records:
- The timestamp of the change.
- The user who made the change.
- The type of event (create, update, destroy).
- The previous and current state of the record.
- Versions are stored permanently and cannot be edited or deleted.
Changes are recorded against the specific user who made them -- whether the change came from the admin panel or from the POS/API. Entries with no identifiable user (e.g., automated background processes) are shown as "System".
Accessing the Audit Trail
- Log in to the Admin Panel.
- Navigate to the Audit Trail page.
- The audit trail loads, showing recent changes across all record types for your store.
The audit trail shows only your own store's history. In the multi-tenant cloud, every version entry, filter dropdown value, and detail/undo lookup is scoped to the current store, so you never see another store's product names, sales, customers, or user emails. Attempting to open or undo a version that belongs to a different store returns "Record not found".
Understanding Version Entries
Each version entry shows:
| Field | Description |
|---|---|
| Time | When the change occurred. |
| Model | The model name (e.g., Product, Sale, User). |
| Item | A human-readable name for the record (see below). |
| Action | Create, Update, or Destroy. |
| Changed By | Who made the change. |
| Actions | View details or Undo the change. |
Human-Readable Item Names
The Item column shows a meaningful display name instead of a bare database ID. The system resolves a friendly label per record type:
- Product in Category -- A product's membership in a category (join-table records).
- Sale #N: Product -- A line item shows which sale and product it belongs to.
- Sale #N payment ($amount) -- A payment shows the sale and the amount.
- Adjustment: Product, Drawer #N, Return #N, and similar friendly labels for other record types.
For anything without a special case, the trail falls back to the record's name, display name, or title. Deleted records that no longer exist are shown as a muted "deleted" label rather than an orphaned ID.
Version Detail Page
When you open a version entry, the detail page is built to be readable by non-developers:
- Plain-language summary -- For common events, the page shows a one-sentence description instead of a raw field dump. Examples: "Added Product to category Category", "Removed Product from category Category", "Created product Name", "Created customer Name", "Deleted product Name", "Completed Sale #N ($total)". For deletions, the previous record's name is recovered from the stored snapshot so the summary is still meaningful even though the record is gone.
- Field-level diff (updates) -- For update events, the page shows a Before / After table that lists only the fields whose values actually changed -- not the full record. Noisy or meaningless differences are filtered out: timestamp-only changes (like
updated_at), values that differ only by type ("7.0"vs7.0), and blank-equivalents (nil, empty string, empty hash/array all treated as the same) are not shown. If only timestamps changed, the page says so explicitly. - Single-state table (create / destroy) -- For create and destroy events there is no meaningful "before" or "after" to diff, so the page shows a single table of the created values, or the deleted record's last known state.
- Raw JSON -- The complete before/after JSON is still available behind a Show raw JSON disclosure for the rare case a developer needs the full payload.
Tracked Record Types
The audit trail covers the following record types:
| Record Type | What's Tracked |
|---|---|
| Products | Name, price, cost, SKU, status, stock, cannabis attributes |
| Users | Name, email, role, status, permissions |
| Sales | Status, total, payment method, void reason |
| Customers | Name, contact info, loyalty tier |
| Categories | Name, sort order |
| Inventory | Stock adjustments, receiving records |
| Store Settings | Tax rates, feature flags, configuration changes |
| Cash Drawer Sessions | Opening/closing balances, overrides |
| Compliance | Equivalency factors, site IDs, limit overrides |
Filtering the Audit Trail
By Record Type
- On the global audit trail page, click the Record Type dropdown.
- Select the type you want to view (e.g., "Product").
- The trail filters to show only changes to that record type.
By User
- Click the User dropdown.
- Select the user whose changes you want to review.
By Event Type
Filter by change type:
- Create -- New records only.
- Update -- Modifications only.
- Destroy -- Deletions only.
By Date Range
- Set From and To dates.
- The trail shows only changes within that period.
If you need to find when a particular field was changed (e.g., "When was this product's price last changed?"), use the audit trail filters to narrow down the record type and scan the version entries for that record.
Undoing Changes
The audit trail includes an Undo button that can reverse changes. Click Undo on any entry to revert that change. The Undo button is available both on the index page (per-row) and on the show page for individual version entries.
When undoing a change, consider the impact on related records. For example, undoing a product price change will not undo sales that were already made at the changed price.
Audit Trail and Compliance
The audit trail is particularly important for regulated industries:
- Cannabis compliance -- Regulators may request a history of inventory and sales changes during an audit.
- Financial audits -- The trail shows all price, cost, and tax configuration changes.
- Employee disputes -- If there is a disagreement about who made a change, the trail provides objective evidence.
- Data integrity -- The trail proves that records have not been tampered with, since versions are immutable.
Audit trail versions cannot be edited or deleted, even by admins. This is by design. The immutability of the trail is what gives it value as an audit tool. If versions could be modified, they would be untrustworthy. The Undo feature creates a new version entry when reverting, preserving the full history.
Storage and Performance
The audit trail stores a version for every change, which can accumulate significant data over time:
- Storage -- The audit trail retains all version history permanently. Large catalogs with frequent changes may accumulate millions of version records over years.
- Performance -- Version queries are indexed for fast retrieval. You should not experience slowdowns when viewing a record's history.
- Retention -- Unlike activity logs, audit trail versions are never automatically purged. This is intentional for compliance purposes.
Audit Trail vs. Activity Logs
| Feature | Audit Trail | Activity Logs |
|---|---|---|
| Granularity | Field-level (what exactly changed) | Event-level (what action was taken) |
| Scope | Record modifications | All system events (logins, exports, etc.) |
| Retention | Permanent (never deleted) | Clearable via Clear All action |
| Use Case | "What was this product's price last month?" | "Who logged in at 3am?" |
Both systems complement each other. Use activity logs for event investigation and the audit trail for data change investigation.
Best Practices
- Use the audit trail when investigating discrepancies -- Before accusing anyone of making an error, check the audit trail. It tells you exactly what happened.
- Review compliance records regularly -- For cannabis retailers, periodically review the audit trail on compliance-related records (equivalency factors, site IDs, limits).
- Document restorations -- When you manually restore a value from the audit trail, add a note explaining why (e.g., "Restored price to $29.99 per manager request").
- Educate your team -- Let employees know that the audit trail exists. Awareness of tracking encourages careful, deliberate changes.
- Use the Undo feature carefully -- The Undo button is powerful. Only use it when you are certain you want to revert a change.
What's Next?
- Activity Logs -- Track user actions and system events.
- Product Issues -- Flag and track product data quality issues.
- Compliance -- Cannabis regulatory compliance tools.