Audit log
Wisteria records every consequential action — content changes, approvals, user changes, settings updates, integration connects — in an audit log. The viewer lives at Audit Log in the sidebar.
Available to: super_admin and auditor only.
What’s logged
Every entry has:
- Action — a dotted-namespace string (e.g.
module.publish,user.role_change,approval.approve) - Actor — the user who triggered the action
- Resource type + Resource ID — what was changed
- Resource name snapshot — the name of the resource at the time of action (so renames don’t lose history)
- Timestamp
Optional extras: a meta blob with action-specific details (e.g. for user.role_change, the previous and new role values).
Filtering
The page has three filters:
- Action — grouped dropdown organised by Module / Course / User / Department / Assignment / Company / etc.
- Actor — pick a specific user
- Date range — From and To, inclusive
Apply applies filters. Clear resets everything to no-filter.
Pagination
50 rows per page. Use the chevron buttons at the bottom to page through. The counter shows X–Y of Z entries.
Exporting
Click Export to Excel to download up to 2,000 matching rows as .xlsx. The export respects whatever filters are currently applied — so if you want everything, clear filters first.
For full bulk export beyond 2,000 rows, contact support.
Action vocabulary
Common actions you’ll see:
| Action | Means |
|---|---|
module.create | New module created (typically inside a new course) |
module.publish | Module published — visible to learners |
module.archive | Module archived |
module.submit_for_approval | Trainer submitted for review |
module.approve | Reviewer approved a module |
module.reject | Reviewer rejected a module with feedback |
module.resubmit_after_rejection | Trainer resubmitted after fixing |
course.create | New course |
course.publish | Course published |
user.create | New user added |
user.role_change | Role changed (meta has before/after) |
user.deactivate | User deactivated |
user.delete | User permanently deleted |
department.create / .update / .delete | Department changes |
assignment.create / .delete | Course assigned / unassigned |
company.update | Workspace settings changed |
integration.connect / .disconnect | Integration connected or removed |
The full list is searchable in the dropdown. Any action not in the dropdown is from a route that hasn’t been added to the filter list yet — file a bug if you find one.
Retention
Audit log entries are retained indefinitely by default. Wisteria doesn’t auto-delete history.
If your organisation has a data retention policy that requires deletion after N years, contact support — we’ll set up a retention rule for your workspace.
What’s NOT in the audit log
- Read events — viewing a course, listing the user roster, etc. Audit log captures changes, not access.
- Learner activity — quiz attempts, flashcard completions, etc. Those go in
activity_log(a separate learner-event table). Available via the Analytics page. - Sign-in events — Supabase Auth tracks these; they’re not duplicated into Wisteria’s audit log.
Why the audit log matters
For compliance-driven customers, the audit log is the answer to:
- “Who approved this content for production?” — find the
module.approveentry. - “When was this learner removed?” — find their
user.deleteentry. - “Who changed this person’s role from learner to trainer?” — find the
user.role_changeentry with their ID.
For everyone else: it’s the answer to “what happened” when you’re trying to retrace something.