Audit log and data export

Wassla records every privileged action — agent edits, channel changes, team membership, billing flips, impersonation sessions, and customer-data exports — to an append-only audit log you can read from the workspace Settings or, for platform staff, from the staff portal. You can export the filtered audit view as a CSV at any time, and customer-level data exports are available as JSON from each customer profile in the inbox.

This guide covers where to find the audit log, what the system writes to it, and how to honor a customer-initiated data export request end to end.

Open the workspace audit log

The workspace audit log is the right surface for owners, admins, and auditors investigating activity inside a single tenant.

  1. In the workspace sidebar, click Settings.
  2. Choose Audit log from the Settings sub-navigation.
  3. The log opens grouped by day, with the most recent entries on top. Each row shows the actor (a teammate name or "System"), a natural-language verb (created, updated, deleted, added, removed, restored), the affected resource, the local time, and the originating IP address when one was captured.
  4. Use the filter chips at the top — All, Agents, Knowledge, Team, Channels, Settings — to narrow the view to a specific surface.

The workspace log only shows events for your tenant. Cross-tenant activity is restricted to the staff portal.

Open the staff (platform) audit log

If you hold a platform_admin_capabilities role (owner, admin, finance, support, or auditor), you can read the platform-wide log from the staff portal.

  1. Navigate to /staff and sign in with your staff credentials.
  2. Click Audit in the staff shell sidebar.
  3. The page loads the 50 most recent privileged events across every tenant on the platform. Click Load more to page through older history.
  4. Filter the view with the chips at the top: All, Impersonation, Billing, Channels, or Destructive (suspend, purge, delete, revoke, refund).
  5. Click Export at the top right to download the currently filtered rows as a CSV named wassla-audit-YYYY-MM-DD.csv. The CSV includes columns for When, Tenant, Actor, IP, Action, and Resource.

Actor emails on the staff page are masked to a single leading letter (for example, l***@example.com) so the export does not unnecessarily expose teammate identities.

What the audit log captures

Wassla writes audit events for two distinct streams, both flowing into the same immutable audit_events table.

Workspace writes (tenant side)

Any insert, update, or delete on a tenant-owned resource is captured automatically. This includes:

  • Agents — create, rename, edit instructions, change voice or language, activate or pause, connect or disconnect knowledge, toggle tools (knowledge search, ticket creation, appointment booking, order lookup, lead capture, human handoff).
  • Knowledge base — create, rename, edit question or answer, move category, publish or hide.
  • Team — invite, role change, remove, restore.
  • Channels — connect, disconnect, reassign an agent.
  • Workspace settings — rename, brand color, logo, plan change.

Staff actions (platform side)

Every action a staff teammate takes through the admin-ops backend routes through a shared writeStaffAudit helper. There are no raw inserts into audit_events from staff code, which means staff activity cannot bypass the log. Captured actions include staff invitations and role changes, tenant suspend and unsuspend, plan and credit adjustments, billing-mode flips, capability grants and revocations, dual-control approvals, refunds, and impersonation sessions (start, stop, and auto-expire).

What is always recorded

For every event the log stores the timestamp, the actor (user id, email, and role), the staff flag, the action verb, the resource type and id, an optional metadata payload describing what changed, the originating IP address, and the tenant id when scoped. The audit_events table has no UPDATE or DELETE policy — not even owners can edit or remove a row. Long-term retention is handled by archival, never by purge.

Export your tenant data on request

When a customer (or your own compliance team) requests a copy of the data Wassla holds on them, the export is a per-customer JSON download initiated from the inbox.

  1. Open the Inbox and search by phone number, email, or any identifier tied to the customer.
  2. Open the customer profile from the conversation header.
  3. Click Export. Wassla compiles a JSON file containing every message, voice transcript, tag, internal note, and conversation linked to that customer and emails the download link to the requesting teammate.
  4. The export request itself is written to the audit log — actor, customer reference, action, timestamp, and IP — so you can prove the request was handled.

For workspace-wide exports — for example, when migrating off Wassla or responding to a regulator — open a ticket from inside your workspace as the owner, or email [email protected] from the owner address on file. Workspace-scoped exports are produced manually within a five business-day window and include conversations, customer records, knowledge base contents, agent configurations, and the full audit history as a CSV bundle.

Honor a right-to-erasure request

For customers exercising deletion rights under GDPR or the Saudi PDPL, see the dedicated guide on deleting customer data. In short: hide the customer from active surfaces immediately, then schedule the full erasure from the customer profile. Both actions are audited automatically, and Wassla never hard-deletes customer data outside the queued erasure flow.

Investigate a specific event

In the workspace log, click any row to expand the before-and-after of the change so you can answer questions like "what did Layla actually rename this agent from?" The expanded view shows the field-level delta in plain language — for example, "Switched to English" or "Turned on appointment booking" — instead of raw column names.

In the staff log, the per-row Resource column shows the resource type and a short id; combine it with the Action and Tenant columns to trace cross-tenant patterns, then pivot to the affected tenant's workspace log for the full before-and-after detail.