Activity Log

Activity Log — simple guide for claimed shop owners

What this page is for The Activity Log shows a chronological record of actions and system events related to your shop: who viewed pages, who updated records, sales created, logins, failed payments, admin changes, and other important events. Use it to audit activity, investigate problems, verify actions taken by staff, and trace issues (failed jobs, missing data, or suspicious access).

Top summary (what you see immediately)

  • Paginated list of activity rows with timestamp, user name (if available), raw action type, HTTP method, and a human-friendly action description.

  • Filters for user name, action type, date range, and sort order.

  • Grouped action types in a dropdown so you can filter by categories (e.g., Sales, Settings, Authentication).

  • View details: open any row to see full metadata — request payload, referer, user agent, IP (if captured), and any attached JSON/event data.

Why it matters: quickly find who did what and when — invaluable for troubleshooting, reconciling disputes, detecting misuse, or auditing staff activity.

Do this now: if something looks wrong in your sales or listings, open the Activity Log, set a date range covering the event, and search by user name or action type.

How to use — quick steps

  1. Dashboard → Store Operations → Activity Log for your claimed shop.

  2. Apply filters:

    • User name (partial search) to show actions by a particular staff member.

    • Action type to focus on specific system routes (e.g., storeoperations.sales-management.store for new sales).

    • Start / End date to narrow to the relevant period.

  3. Sort by created_at or other columns (ascending/descending) to find the most recent or earliest events.

  4. Scan the description column (friendly text derived from action type) to quickly understand each entry.

  5. Open a row (View) to inspect full details: raw payload, IP/user-agent, referer, request body, and any error messages.

  6. Group / filter by category using the grouped action types dropdown for targeted audits (e.g., only “Viewed sales” or only “Authentication” events).

  7. Take action based on findings: correct data, interview staff, escalate to support, or secure accounts.

What each field means (plain language)

  • Timestamp / created_at: when the event was recorded.

  • User name: the account that triggered the event (may be missing for anonymous visitors).

  • Action Type (raw): internal route or action name (useful for exact lookups). Example: storeoperations.sales-management.store.

  • Method: HTTP method (GET, POST, PATCH, DELETE) — helps understand if it was a read or write action.

  • Action Description: user-friendly summary (e.g., “Submitted new sale”, “Viewed shop analytics”). Use this first — it’s easier than decoding route names.

  • Details / payload: full JSON or form data recorded with the event — useful for debugging (e.g., which product SKU was sold).

  • IP / User Agent / Referer: technical context showing where the request came from and what device/browser was used.

  • Status / error (if any): whether the action succeeded or logged an error message.

Common use-cases & examples

  • Investigate a missing sale: filter action_type = storeoperations.sales-management.store and the sale created_at window — open the row to see order payload and who created it.

  • Verify staff changes: search profile.update or storeoperations.product-management.index to see who edited product info and when.

  • Check suspicious logins: filter login actions and password.reset events to find failed or unusual authentication activity.

  • Confirm a refund was processed: filter credit-note and refund-related routes (e.g., storeoperations.credit-note.index) and inspect payloads for amounts and authorizing user.

Tips for effective auditing

  • Start with a narrow date range (the hour or day the event happened), then expand if you don’t find it.

  • Search by user name if you have suspect staff changes — partial matches work.

  • Use action description first — it’s human-readable and grouped by category.

  • When viewing a row, copy the raw payload into your support ticket or bookkeeping notes — it speeds up reconciliation.

  • Look at referer and user-agent to see if an action came from the POS terminal, a staff laptop, or an external system/integration.

  • If you see repeated failed actions (same IP or user), consider rotating access keys, forcing password resets, or restricting IPs.

Edge cases & validation

  • Not all events have user names — public visitors or automated systems may show no account. Use IP and referer instead.

  • Action types are raw route names — if you need exact technical matching, use the action_type field; for a quick read, rely on the action description.

  • Logs may be paginated — check earlier pages or increase per-page size when searching older events.

  • If a row has limited details it may be due to logging limits or data truncation; note the timestamp and escalate to support with that ID.

  • Retention: logs may be retained only for a certain period — export or snapshot important findings promptly.

Quick troubleshooting (what to do when things look off)

  • I can’t find the event: expand date range, try partial user name, or search by the action_type raw string.

  • Details are missing or truncated: note the row id/timestamp and contact support with that reference.

  • Multiple suspicious logins from one IP: lock the account, force a password reset, and review recent actions by that user.

  • An action shows an error message: copy the error text and payload; open a support ticket and include the action_type, timestamp, and user name.

  • Activity log page won’t load: try again after a few minutes — tenant DB connections are required; if persistent, contact support.

Action plan — what to do in the next 10 / 30 / 60 minutes

10 minutes

  • Open the Activity Log and filter by the last 24 hours. Scan for error descriptions or repeated failed events.

30 minutes

  • If you find anomalies (failed payments, unexpected deletes): open each event row, copy payloads, list impacted orders/products, and save a short incident note.

60 minutes

  • Secure any compromised accounts (change passwords, revoke API keys), inform affected staff, and open a support ticket with copied log entries for deeper investigation.

FAQ (quick answers)

Q: Who can access the Activity Log? A: Typically claimed listing owners, admins, and staff with permissions. If you can’t access it, check your account role or ask the owner/admin to grant access.

Q: How far back do logs go? A: Retention settings vary. If you need older logs, export what's available and contact support for retention policies or archival retrieval.

Q: Are logs tamper-proof? A: Logs are intended for operational auditing. For high-assurance needs, coordinate with DialMyStore support about immutable audit archives.

Q: Can I export logs? A: If export is available on the page, use it to create offline records. Otherwise, copy the relevant payloads and timestamps for support or accounting.

Who should use this and how often

  • Shop owner / manager: weekly checks and after any incident.

  • Store supervisors / cashiers: daily quick checks in high-risk environments (refunds, high-value items).

  • Accountant / auditor: during monthly reconciliation or during audits.

  • Support / Ops: on-demand to resolve tickets and incidents.

PreviousTaxNextFinancial Analytics

Last updated