Skip to content

Activity log

Audit every create, update, delete, assign, and sign-in action. The activity log is an append-only record of who did what, when.

Required role

Admin. Auditors typically access through the Viewer role (read-only) if your installation scopes it that way.

Overview

The activity log is the audit trail of your company's tenant. It answers "who changed this?" and "when did that happen?" questions across:

  • User management actions (create / edit / deactivate users, role changes, password resets).
  • Hierarchy changes (create / edit / move / delete nodes).
  • Task lifecycle events (assign, reassign, submit, approve, reject).
  • Master data edits (thresholds, units, products, tools).
  • Configuration changes (company settings, feature flags, notification rules).
  • Sign-ins and sign-outs.

Every entry is append-only — you can't edit or delete entries. That's the point; an audit trail you can alter isn't an audit trail.

Prerequisites

  • You have the Admin role.

Open the activity log

Settings → Activity log, or Admin → Activity log depending on your installation.

You see a table:

Column Meaning
Time When the action happened, in your timezone.
User Who did it — includes their role(s) at time-of-action.
Action create / update / delete / assign / sign_in / etc.
Subject What the action was on — user, task, asset, etc.
Summary One-line plain-English summary.
Details "View details" → full JSON of before / after state.

Filter the log

A filter bar at the top narrows by:

  • Date range — day / week / month / custom.
  • User — pick one or many.
  • Action — create / update / delete / assign / approve / reject / sign_in / sign_out.
  • Subject type — User / Task / Asset / Component / Shutdown / Repair request / etc.
  • Free-text search — matches across summary and details.

Filters combine. A typical audit query: "all deletes by user X in October".

View an entry's full details

Click View details on any row. You see:

  • The action's timestamp (UTC + local).
  • The actor's full name, email, role at that moment.
  • The subject (entity type + ID, linked to the current view of that entity if it still exists).
  • Before state — JSON snapshot of the entity before the change.
  • After state — JSON snapshot after.
  • IP address — if your installation records it.
  • User agent — browser / mobile app + version.

For deletions, "after state" is null and "before state" is the last known good snapshot.

Export

Two formats:

  • CSV — one row per entry, columns same as the table.
  • JSON — one entry per object in an array, includes full before / after state.

Exports reflect your current filter state. Useful for:

  • External audit.
  • Compliance packs for certification reviews.
  • Incident-response investigation.

For large exports (> 10,000 entries), the portal queues a background job and emails you when the file is ready.

Retention

Default retention: 7 years on most installations (driven by regulatory norms). Customer Admins can't change retention — it's set at the installation level by PegotecUser.

Entries older than the retention window are archived (moved out of the active table) but remain recoverable via a support case for legal / regulatory needs.

Common investigations

"Who deleted this asset?"

  1. Activity log.
  2. Filter: Action = delete, Subject type = Asset.
  3. Date range = window you think the deletion happened.
  4. Scan the results; look for the matching asset name in the summary.

Result gives you the user, the timestamp, and the before-state so you can recover via Recycle Bin if still within window.

"Did user X change the threshold yesterday?"

  1. Activity log.
  2. Filter: User = X, Subject type = Threshold.
  3. Date = yesterday.
  4. Review the before / after states.

"Who signed in from IP Y?"

  1. Activity log.
  2. Filter: Action = sign_in.
  3. Search for the IP in the free-text box.
  4. Results show every sign-in from that IP (if your installation records IP).

"Monthly access report for auditor"

  1. Date = last full calendar month.
  2. Filter: Action = sign_in (or leave broad if the auditor wants everything).
  3. Export → CSV.
  4. Attach to the audit pack.

What the log does NOT record

  • Read operations — viewing a task, opening a report. These don't write to the audit log because they'd drown signal-of-interest in background noise.
  • Automatic background jobs — the scheduler generating daily task instances, the weekly report email. Those are system-level and logged separately if your installation needs them.
  • Mobile device actions that never sync — a technician who starts a task offline and then uninstalls the app without syncing leaves no trace.

Things to watch for

Don't rely on the log for real-time monitoring

The activity log is an after-the-fact audit. For real-time ops visibility, use the Dashboard and notifications. The log tells you what happened; the Dashboard tells you what's happening.

Filter before you scroll

With an active plant, hundreds of entries per day are normal. Filters make the log usable — scrolling raw rarely works.

Entries preserve user context at time-of-action

If a user had the Supervisor role yesterday and the Mapper role today, yesterday's entry shows them as Supervisor — not whatever their current role is.

Troubleshooting

Problem Fix
An expected entry is missing Confirm the user was signed in at that time; confirm the action triggered a log entry (reads don't)
Filter returns nothing Widen the date range first; filters default to tight windows
Export times out Narrow the range; large exports run as background jobs — watch your inbox
Can't find the "audit log" menu Your role may not include audit.view — request from an Admin