Audit log
Callstrike keeps a tenant-scoped, append-only audit trail of every meaningful admin action across the platform, campaigns, targets, templates, voices, simulations, members, integrations, SSO, and data-retention changes. Each record captures who did it, what they did, what it affected, when, whether it succeeded, and the request's source IP, user-agent, and correlation id. The trail is written through a single centralized capture path (no per-feature logging to keep in sync), is tamper-evident via a per-tenant hash chain, and can never be edited or deleted through normal use, only a controlled GDPR erasure path can redact the personal identifiers inside a record, and even that leaves the event and the chain intact. It exists to answer the auditability question enterprise buyers ask: "can you show us exactly what happened in our account, and can we trust that the record wasn't altered."
Prerequisites
- You need to be an authenticated tenant admin: access to the viewer and export is gated the same way as the rest of Settings, and every read is scoped to your own tenant. You can never see another tenant's records.
- There's nothing to provision or turn on: capture runs automatically for the covered action types the moment they happen.
How to use it
- Open Settings → Compliance and select the Audit Log sub-tab (it sits alongside Retention & Contact, In-call Education, Transparency, and Data & Privacy).
- The trail loads newest-first, showing Timestamp, Actor, Action,
Target, and Outcome for each event. Actions render in a readable
Entity verbform (e.g.campaign.created→ "Campaign created"); a failed action shows outcome failure. - Use Previous / Next to page through history. Paging is keyset-based (not offset scanning), so it stays fast no matter how deep you go, and it never skips or repeats a row.
- Click Export CSV to download the tenant's full trail (timestamp, actor name/email, action, target type/id, outcome) as a CSV file, streamed so large trails don't time out.
- If a tenant has no recorded events yet, the tab shows an empty state instead of an empty table or an error.
Configuration & options
There is no per-event configuration; capture is automatic. The one tenant-level setting is the retention window:
| Option | What it does | Default | Notes |
|---|---|---|---|
| Audit retention window | How long audit records are kept before automatic expiry | 24 months (platform default) | Per-tenant override stored on the tenant record; changing it is itself an audited action (retention_config.updated) |
Captured action types (non-exhaustive; new actions require no schema change, just a new value): campaign create/update/launch/pause/delete; target create/import/update/delete; template create/update/delete; voice cloning and voice use; deepfake and voice-impersonation session start/end; WhatsApp campaign create/update/delete; member invite/role-change/removal; integration connect/disconnect; SSO config updates; retention config updates; and the audit system's own retention-expiry and subject-erasure events.
Gotchas & limitations
- v1 has no filtering. You can page through the trail, but there's no filter by action type, date range, actor, or IP yet; the API and schema are built so filters are cheap to add later; they just aren't exposed in the UI today.
- A deleted actor doesn't erase their history. If the admin who performed an action is later removed from the platform, their events still render using a stored identity snapshot (name/email at the time of the action), rows never go blank or disappear.
- This is not the same as the operational activity log. That log still exists separately; the audit trail is a distinct, first-class compliance store and doesn't replace it.
- Records can't be edited or deleted by any admin, tenant or platform, through normal operation. The only way personal data ever changes inside a record is the controlled GDPR erasure path, which redacts identifiers (name/email/IP/user-agent) in matching rows while leaving the event, its target, its outcome, and the hash chain intact.
- Bulk actions collapse to one record. A CSV import of many targets, for example, produces a single summary event carrying counts in its metadata rather than one row per affected entity.
- Background/system actions aren't skipped. Actions that originate off a human request (scheduled jobs, retention expiry itself) are recorded with a system actor instead of being dropped or misattributed.
- No cross-tenant view. v1 is strictly per-tenant for tenant admins, there's no platform-wide audit console across tenants.
- No real-time alerting. The trail is for after-the-fact review and export; it doesn't push notifications or forward to a SIEM.
Best practices
- Treat the export as the artifact to hand to auditors or compliance reviewers; it carries the same core fields as the on-screen viewer, scoped to your tenant only.
- If you need a longer (or shorter) retention window than the 24-month default for compliance reasons, set the per-tenant override rather than relying on the platform default, since the default can change.
Troubleshooting / FAQ
Why don't I see an event for something I just did? Freshness is near-real-time, not instant; capture is decoupled from the request path so the underlying action is never blocked or slowed down by audit logging. Give it a moment and refresh.
Can I recover or filter to a specific person's or campaign's history? Not yet in the UI, v1 ships with pagination only. By-actor and by-target lookups are supported at the data layer and are planned as a UI filter.
What happens to my tenant's audit trail under GDPR erasure? A subject's personal identifiers (name, email, IP, user-agent) are redacted from matching records, but the event itself, what happened, to what, when, and with what outcome, stays in the trail, and the hash chain still verifies. The erasure itself is recorded as an audit event.