{"title":"Track activity with the audit log","slug":"audit-log","url":"https://support.storeconnect.com/articles/audit-log","url_markdown":"https://support.storeconnect.com/articles/audit-log.md","subtitle":null,"summary":"Keep a security-focused record of significant events in your store, including logins, password and account changes, payments, and point-of-sale activity. Set the logging level, the categories recorded, and the retention period for each store.","type":"Help_Documentation","video_url":"","keywords":"audit log, audit trail, security log, audit log level, login history, payment audit, risk screening, compliance, retention, point of sale audit, event log, who changed","last_modified":"2026-10-07T05:47:34+0000","body_markdown":"The audit log records security- and business-significant events in your store, so you can see who did what, when, and to which record. Each event is stored as an **Audit Log** record (`s_c__Audit_Log__c`) capturing what happened, when it occurred, who performed it, the outcome, and links to the records involved.\n\nUse the audit log for security reviews, troubleshooting, and compliance. Records are written automatically as customers and staff use your store, but you can choose how much detail to keep.\n\n:::note\nAudit log records are append-only. They are created automatically and are never edited afterward, so they reflect exactly what happened at the time of the event.\n:::\n\n## What gets recorded in the audit log\n\nEvents are grouped into categories. Each event has a fixed severity, which decides whether your store's logging level records it, and a default retention period suited to its sensitivity.\n\n| Category | Event | Severity | Default retention |\n|---|---|---|---|\n| Authentication | Signup | `NOTICE` | 365 days |\n| Authentication | Login | `NOTICE` | 90 days |\n| Authentication | Login Failed | `WARNING` | 365 days |\n| Authentication | Logout | `INFO` | 90 days |\n| Password | Password Reset Requested | `NOTICE` | 365 days |\n| Password | Password Reset Completed | `WARNING` | 365 days |\n| Password | Password Changed | `WARNING` | 365 days |\n| Invitation | Invitation Sent | `NOTICE` | 365 days |\n| Invitation | Invitation Accepted | `NOTICE` | 365 days |\n| Account Changes | Email Changed | `WARNING` | 730 days |\n| Payments | Payment Attempted | `NOTICE` | 2555 days |\n| Payments | Payment Failed | `WARNING` | 2555 days |\n| Payments | Payment Succeeded | `NOTICE` | 2555 days |\n| Payments | Risk Screening Approved | `NOTICE` | 2555 days |\n| Payments | Risk Screening Declined | `WARNING` | 2555 days |\n| Payments | Risk Screening Error | `WARNING` | 2555 days |\n| Payments | Risk Screening Review | `WARNING` | 2555 days |\n| Payments | Risk Decision Updated | `WARNING` | 2555 days |\n| POS | POS Register Login | `NOTICE` | 365 days |\n| POS | POS Shift Started | `NOTICE` | 365 days |\n| POS | POS Shift Ended | `NOTICE` | 365 days |\n| Custom | Any event your theme records, see [Track custom audit log events](#track-custom-audit-log-events) | `NOTICE` | 365 days |\n\nThe five risk events are recorded only when risk screening is configured for your store. If you do not use risk screening, no risk events appear.\n\n## Logging levels\n\nSeverity ranks from lowest to highest: `INFO`, `NOTICE`, `WARNING`, `CRITICAL`. **Audit Log Level** sets the lowest severity a store records, so each level records its own severity and everything above it.\n\n| Level | What it records |\n|---|---|\n| `Off` | Nothing |\n| `Essential (warnings and above)` | `WARNING` and `CRITICAL` events, such as failed logins and password changes |\n| `Standard (notices and above)` | Adds `NOTICE` events, such as successful logins and payments. This is the default when the field is blank |\n| `Verbose (everything)` | Adds `INFO` events. `Logout` is the only standard event at this severity |\n\n:::tip\nKeep the level at `Standard` unless you have a reason to change it. Choose `Verbose` for the fullest possible trail, or `Essential` when you only need high-signal security events.\n:::\n\n## How categories narrow what gets recorded\n\n**Audit Log Categories** limits a store to recording only the categories you select. Leave it blank to record every category, which is the default.\n\nA record is written only when it passes both checks: its severity meets the store's **Audit Log Level**, and its category is one the store records.\n\n## Configure the audit log for a store\n\nThree fields on the **Store** record control what a store records.\n\n| Field | API name | Purpose |\n|---|---|---|\n| **Audit Log Level** | `s_c__Audit_Log_Level__c` | The lowest severity recorded. Blank records at `Standard` |\n| **Audit Log Categories** | `s_c__Audit_Log_Categories__c` | The categories recorded. Blank records all categories |\n| **Audit Log Retention (Days)** | `s_c__Audit_Log_Retention_Days__c` | Minimum days to keep records. Blank uses each event's default |\n\n![Audit log settings in the sotre record](https://res.cloudinary.com/hzkr6fi81/image/upload/v1791234736/media/AuditLogCategories.png)\n\n### Before you begin\n\n- You need edit access to the [store record](store-setup).\n- Decide which categories you need to record, and how long you need to keep them. Regulated industries often set retention explicitly rather than relying on the defaults.\n\n### Steps\n\n1. Open the **Store** record.\n2. Set **Audit Log Level** to `Off`, `Essential`, `Standard`, or `Verbose`.\n3. (Optional) Set **Audit Log Categories** to the categories you want recorded. Leave it blank to record all categories.\n4. (Optional) Set **Audit Log Retention (Days)** to keep records longer than their defaults, for example to meet a regulatory requirement in your industry or region. See [How long audit records are kept](#how-long-audit-records-are-kept).\n5. Save the **Store** record.\n\nThe settings apply to events that occur after you save. New activity now appears as **Audit Log** records at the level you selected.\n\n## View audit log records\n\nIn the StoreConnect Console, click **Setup** (the gear icon in the top right) and choose **Audit Log** under **Tools**. You can also search for **Audit Log** in the App Launcher. Four list views are provided: **All**, **Recent Security Events**, **Failed Logins**, and **Failed Payments**.\n\n![The Setup menu in the StoreConnect Console with Audit Log listed under Tools](https://res.cloudinary.com/hzkr6fi81/image/upload/v1790818593/media/audit-log-console-setup-menu.png)\n\nAudit records are read-only for everyone. Salesforce system administrators can see them, and every other user, including StoreConnect administrators, needs the **StoreConnect Audit Viewer** permission set. It grants read access to every audit record and nothing else, and the **StoreConnect Administrator** permission set does not include it.\n\nEach record captures:\n\n- **Event Type**, **Category**, and **Occurred At**, which holds the time to the second. **Occurred At Precise** holds the same instant with microseconds, so you can order events that happened within the same second.\n- **Actor Type**, which is `Contact`, `User`, or `System`, and **Actor Label** and **Actor Email**, the name and email as they were when the event occurred. **Actor Contact** and **Actor User** link to the record that acted.\n- **Outcome** and **Channel**. Channel is `web`, `pos`, `admin`, `api`, or `system`. See the outcome values below.\n- Lookups to the records involved: **Account**, **Contact**, **Store**, **Order**, **Cart**, and **Payment**, plus **Outlet**, **Register**, and **Register Shift** for POS events.\n- **Message**, a short summary, and **Details**, event-specific JSON.\n- **IP Address** and **User Agent**, the address and browser or device the event came from.\n- **Event Link**, a link to the event in the system it originated in, where one exists. Risk screening events use this to link back to the provider's record of the decision.\n\n:::note\nA failed login has no resolvable identity, so **Actor Type** is `System` and **Actor Label** holds the username that was attempted.\n:::\n\n### Outcome values\n\n| Outcome | Meaning |\n|---|---|\n| `success` | The action succeeded, including a risk screening that approved the order |\n| `failure` | The action failed |\n| `pending` | The action has not completed |\n| `flagged` | Risk screening sent the order for manual review |\n| `monitored` | Risk screening declined the order while in monitor-only mode, so the order was not blocked |\n| `enforced` | Risk screening declined the order and it was blocked |\n| `failed_open` | Risk screening could not complete and the order was allowed through |\n| `failed_closed` | Risk screening could not complete and the order was blocked |\n| `updated` | The risk provider revised an earlier decision |\n\nAudit records also appear as an **Audit Logs** related list, newest first, on the **Account**, **Contact**, **Store**, **Order**, **Cart**, **Payment**, **Register**, and **Outlet** records, so you can review the history of a single record without filtering the whole log.\n\n:::tip\nRecord names are formatted `AL-\u003cOccurred At Precise\u003e`, so sorting a list view by **Name** sorts it chronologically.\n:::\n\n### Export audit records\n\nAudit Log is a standard Salesforce custom object, so you export it the same way as any other object. There is no separate export button.\n\n- **Reports**: create a report on the **Audit Logs** report type, filter it to the records you need, and export it to CSV or Excel. This is the simplest option for a one-off review or for an auditor.\n- **Data Loader or the Bulk API**: extract `s_c__Audit_Log__c` in bulk, for example to archive records before they pass their retention period or to load them into a SIEM or data warehouse.\n- **Data Export**: include the object in your scheduled Salesforce data export to keep a regular offline copy.\n\n## How long audit records are kept\n\nEach event type has a default retention period, listed in the table above. Payment events are kept for 2555 days (about seven years), while routine logins and logouts are kept for 90 days. Records past their retention period are purged automatically.\n\nTo keep a store's records for longer, set **Audit Log Retention (Days)** on the **Store** record. It acts as a floor: records are kept at least that many days, even where an event type's default is shorter. It never shortens retention. Leave it blank to use each event type's default.\n\nSalesforce is the system of record for retention. Your online store keeps its own copy for twice the event type's default as a safety net, so a record can disappear from the store's database while remaining in Salesforce.\n\n## Track custom audit log events\n\nIf you build or customize your store's theme, record your own events from Liquid with the [`audit_event` tag](audit-event-tag-reference). Use it for actions that matter to your business but are not standard StoreConnect events.\n\nLiquid has no way to write an object literal, so build the `detail` value with the `deserialize` filter and pass the result:\n\n\n```liquid\n\n{%- assign tier_detail = '{\"from\":\"silver\",\"to\":\"gold\"}' | deserialize -%}\n{% audit_event \"loyalty_tier_changed\",\n   message: \"Customer reached Gold\",\n   detail: tier_detail %}\n```\n\n\n| Parameter | Required | Description |\n|---|---|---|\n| First argument | Yes | Your event name, in quotes. Recorded in **Custom Event Name** |\n| `message` | No | A short summary, up to 255 characters |\n| `detail` | No | Event-specific detail, stored as JSON in **Details**. Build it with `deserialize` |\n\nEvery entry the tag makes is recorded with **Event Type** `custom`, **Category** `CUSTOM`, and **Severity** `NOTICE`. A theme cannot record an entry that looks like a standard event such as `login` or `payment_succeeded`.\n\nThese limits apply automatically:\n\n- Because custom entries are `NOTICE`, they are recorded only when the store's **Audit Log Level** is `Standard` or `Verbose` and the `Custom` category is recorded.\n- Ten entries per request. Further calls in the same request are ignored silently, so do not put the tag inside a loop over products or cart items.\n- Any key in a structured `detail` whose name contains `password`, `passwd`, `secret`, `token`, `api_key`, `apikey`, `_key`, `crypt`, `salt`, `certificate`, `card_number`, `cardnumber`, `authorization`, `ssn`, or `otp`, or is exactly `pan`, `pin`, `cvv`, or `cvn`, is stored as `[FILTERED]`. A key that names a secret any other way, such as `social_security_number` or a bare `key`, is stored as written. Filtering matches key names, so it cannot redact a secret buried in a plain string.\n- A failed write never breaks the page. If the entry cannot be recorded, the tag renders nothing and the page continues. An undefined variable passed as `message` or `detail` still shows a Liquid error.\n- `message` is truncated at 255 characters and `detail` at 32768, so a `detail` over the limit is stored as incomplete JSON.\n\nThe tag is not available in POS templates.\n\n:::warning\nDo not pass sensitive data such as card numbers, passwords, or secrets in `message` or `detail`. The filter catches obvious secrets by key name only, and you remain responsible for what your theme passes in.\n:::\n\nNames and email addresses are deliberately not filtered from **Details**, in any event. Knowing who did something is the purpose of an audit record, so treat the audit log as a store of personal data when you plan your data-retention and privacy obligations.\n\n## Troubleshooting\n\n### No audit records are being created\n\nCheck **Audit Log Level** on the **Store** record. If it is set to `Off`, nothing is recorded. If it is blank, the store records at `Standard`.\n\n### Logout events are missing\n\n`Logout` is the only standard event with `INFO` severity, so `Standard` does not record it. Set **Audit Log Level** to `Verbose` to capture it.\n\n### A record shows the wrong name or email for the actor\n\n**Actor Label** and **Actor Email** are snapshots taken when the event occurred, and are deliberately not recalculated. A record showing an old name or email is correct: it shows the values as they were at the time of the event.\n\n### I see two records for the same email change\n\nWhen a customer changes their email address on your online store, the change is recorded there with the customer as the actor. When the contact syncs to Salesforce, the update is recorded a second time with the integration user as the actor and `admin` as the channel. Both records are accurate: one captures the change where the customer made it, the other captures the record changing in Salesforce.\n\n### I need to correct or delete an audit record\n\nYou cannot. Audit records are append-only, and the Salesforce integration user has create-only access, so records cannot be altered or removed after they arrive. Records leave the log only when they pass their retention period."}