What the log records
The log captures two kinds of activity:- Business operations. Every time a business record is created, updated, or deleted across the workspace — orders, styles, quotations, purchase orders, shipments, invoices, foreign-exchange rates, vendor payments. The entry names the record by its business key (the order number, the style code, the invoice number), not an internal identifier.
- The security trail. Sign-ins, sign-outs, failed sign-in attempts, session revokes, every user-management action (invite, role change, activate, deactivate, password reset, two-factor enabled or disabled), and every change made on the Settings page itself.
Who can see and configure it
Only an administrator can open the Audit Log tab and configure the audit level and retention. Every other role sees “Access denied. Admin only.” when the tab opens.Reading an entry
Every entry on the page carries the same six columns, read left to right:Date— the date and time the action happened, in your local time zone.User— the person who did it, shown by name. The name is captured at the time of the action, so an entry still shows the correct name even after the user account is later deleted. A sign-in by an unauthenticated visitor (for example, a failed sign-in) carries no user.Action— what they did, in short form. Sign-ins, sign-outs, failed sign-ins, and session revokes appear as authentication actions. Changes to a user appear as user actions (role changed, activated, deactivated, password reset, two-factor enabled or disabled). Changes to the Settings page appear as a settings update. Business operations appear as a Create, an Update, or a Delete.Resource— the record the action touched, named by its business key — an order number such asORD-2026-0036, an invoice number, a style code. The business key is a link: clicking it pins that record’s full history on the page (see Pinning an object’s history).Location— the city or region the request came from, where the workspace can determine it. Useful for spotting a sign-in from somewhere unexpected.Details— a short summary of what changed. For sign-in actions, it shows the browser and operating system the request came from (so you can recognise “Chrome / macOS” as your own laptop versus a sign-in from an unfamiliar device). For a single-field change, it shows the field name and its before-and-after values. When several fields change in the same action, the entry collapses into one row with N fields changed; a chevron at the start of the row expands it to show each field’s change one line at a time.
Filtering and search
A row of controls above the table narrows what the page shows. They combine — set as many as you need.From dateandTo date— limit the entries to a date range. Leave either end blank to leave it open.User— show only the entries for a specific user. The picker lists every user on the workspace, with an All users entry at the top.Object type— show only one kind of business record. The picker has an All objects entry at the top and groups forOrders,Styles,Quotations,Purchase Orders,Shipments,Invoices, andFinance(the Finance group covers exchange-rate updates and vendor payments).Action— show only one kind of action. Common picks areCreate,Update, andDeletefor business operations, or the named user-management and authentication actions for the security side.Find object— type a business key (for example,ORD-2026-0036or a style code) and choose “Search” to show every entry that touches that record. The search matches the business key, not free text in the details.Show security events— a checkbox that folds the sign-in and user-management trail back into the listing. Off by default so the page reads as a business-change browser.
Pinning an object’s history
The business key in theResource column is a link. Clicking it pins that
record’s full history on the page — every entry where that order or style was
touched, in time order. A banner above the table reads History for
followed by the record’s business key, with a Clear button to unpin.
This is the fastest way to answer “what has happened to this order since it
was confirmed” or “who has touched this style this season” — pin the record,
optionally narrow the date range, and read the trail.
The audit level
The audit log records a different amount of business activity depending on which Audit Level is set for the workspace. The level is a single setting near the top of the page; an administrator changes it and the workspace begins recording at the new level immediately. Past entries are not rewritten. Three levels are offered:- Security Only. The lightest level. The security trail is the whole log: sign-ins, sign-outs, failed attempts, session revokes, every user-management action, and every change to the Settings page. Business operations are not recorded. Choose this level if you only need a sign-in and admin-action trail and have no wider audit requirement.
- Standard (Recommended). The default for a new workspace. Records the security trail in full, plus every Create and Delete across business records — orders, styles, quotations, purchase orders, shipments, invoices, and finance entries. Routine field-by-field updates are not recorded, but security-relevant updates (role changes, settings changes, quotation changes) are still recorded. Enough for most teams to answer “who created this order” or “who deleted this style” without flooding the log with line-edit entries.
- Full. Records everything Standard records, plus every Update — every field change on every business record. This produces a high volume of entries and is intended for workspaces with an external compliance or audit requirement that requires it. Turn it on deliberately.
Retention
The Audit Retention (days) setting controls how long an entry is kept before it is removed. The default is 365 days. The setting accepts a value between 1 and 3650 (ten years). Entries older than the retention window are pruned automatically each day. Entries inside the window are kept untouched, and the prune runs per tenant so it never crosses workspaces. Pick a value, choose Save to apply it. Lengthening the window does not recover entries that have already been pruned — choose a value that matches your longest plausible audit-lookback need from the start.When the log is most useful
A few situations where administrators reach for the audit log:- Tracking back a change. When someone notices an order, style, or invoice is not what it should be, pin the record and read its history — at Standard the Create and Delete entries point to who and when; at Full every field change is there.
- After a deactivation. Before deactivating a user, filter the log by that user to see what they last did — the audit log tells you whether a handover is needed.
- After a sign-in alert. If a user reports a sign-in they did not make,
turn on Show security events, filter by that user, and read the
LocationandDetailscolumns to tell whether the alert is genuine and what device or browser was used. - Compliance reporting. Where an external auditor asks for a sign-in trail or a record-change trail, the audit log is the canonical source — set the retention window long enough to span the period the auditor will ask about.