Skip to main content
The Audit log is GarmentFlow’s record of who did what across the workspace. Each entry names the person who took the action, the kind of action they took, the business record they touched (an order, a style, a quotation), and the time — shown in plain business terms, never as internal identifiers. It is the page you open when you need to answer “who changed this order,” “who deleted this style,” or “what did this account touch in the last week.” You reach it from the Settings page, on the Audit Log tab.

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.
How much of the business side gets recorded is controlled by the audit level. The security trail is always recorded. By default the page shows business operations only. A Show security events toggle above the table folds the security trail back in.

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 as ORD-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.
The list is ordered with the most recent entry at the top. Use the and controls at the foot of the table to scroll back through older entries; 50 entries fit on a page, and the total entry count appears alongside the controls. A row of controls above the table narrows what the page shows. They combine — set as many as you need.
  • From date and To 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 for Orders, Styles, Quotations, Purchase Orders, Shipments, Invoices, and Finance (the Finance group covers exchange-rate updates and vendor payments).
  • Action — show only one kind of action. Common picks are Create, Update, and Delete for business operations, or the named user-management and authentication actions for the security side.
  • Find object — type a business key (for example, ORD-2026-0036 or 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.
Changing any filter jumps the page back to the first page of results.

Pinning an object’s history

The business key in the Resource 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.
The drop-down shows a short description of what each level covers. Pick a level and choose Save to apply it.

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 Location and Details columns 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.