Admin data export

Build a single ZIP of your organization's user data for compliance, migration, or audit.

The admin export is available from two surfaces:

• Bulk action on the Users page — select users with the checkboxes (up to 200, or everyone through Select all that match), then choose Export data in the bulk bar.
• Organization → Profile → Account → Export organization data… — everyone, the people you pick, or everyone except the people you leave out, with an optional date range.

Either way the export is built in the background as a job, and you are emailed a link when it is ready; if it fails, you are told in your inbox and by email.

Both paths require the Manage compliance permission (canManageCompliance) — the same permission that governs audit retention. They are also gated by Member chat oversight (see below).

Oversight gate

A bulk export returns full chat message content, so it rides your organization's Member chat oversight switch — the same control that governs reading member conversations.

Alert

If Member chat oversight is off, every export path returns 403 Member chat oversight must be turned on under Organization › Data and privacy to export member data. (with code: "oversight_off"). Turn it on under Organization → Data and privacy → Oversight before exporting. The per-user export is gated the same way; its button says so under the row and requests nothing.

This is deliberate: a people-manager should not be able to exfiltrate chat history with no oversight control switched on.

What the export contains

The ZIP has one folder per user, plus organization-level files at the top of the archive:

manifest.json                          ← exporter, requester, range, per-user summary, truncation notes
org_groups.json                        ← the org's group catalogue (name, description, SCIM external id)
org_group_members.json                 ← who belongs to each group
TRUNCATION_NOTICE.txt                  ← only when a safety cap cut something (see below)
<email-1>/profile.json                 ← Profile
<email-1>/settings.json                ← Settings
<email-1>/memory.json                  ← Memory
<email-1>/connections.json             ← Connections (account email and display name; never tokens)
<email-1>/access.json                  ← Database and extension access
<email-1>/groups.json                  ← Groups
<email-1>/conversations.json           ← Conversations, deleted ones flagged
<email-1>/messages.json                ← Messages, from every storage tier
<email-1>/checklists.json              ← Checklists
<email-1>/subagent_runs.json           ← Sub-agent tasks
<email-1>/artifacts.json               ← Dashboards and workspaces
<email-1>/files.json                   ← File list (name, type, size, date)
<email-1>/agents.json                  ← Agents
<email-1>/agent_runs.json              ← Agent runs
<email-1>/inbox.json                   ← Inbox
<email-1>/recaps.json                  ← Recaps
<email-1>/help_chats.json              ← Help assistant chats
<email-1>/support_tickets.json         ← Support requests
<email-1>/feedback.json                ← Feedback sent to Kronisys
<email-1>/email_templates.json         ← Email templates
<email-1>/skills.json                  ← Skills
<email-1>/sessions.json                ← Sign-ins
<email-1>/api_keys.json                ← API keys
<email-1>/audit.json                   ← Activity record
<email-1>/usage_log.json               ← Usage log
<email-1>/usage_ledger.json            ← Credits and limits
<email-1>/analytics.json               ← Usage
<email-1>/export_info.json             ← what this folder covers, and anything that could not be read or was cut
<email-2>/…

Folder names use the user's email with characters outside A-Za-z0-9._@- replaced by _. An export of one member also carries the contents of the files in files.json, newest first, up to 200 MB, in an attachments/ folder; a file left out (too big for what is left, missing from storage) is named in export_info.json. An export of several members carries the list only, and says so in each export_info.json. Group membership and extension grants are included so a subject-access or data-portability request is answered completely — the group catalogue and each user's own membership slice, and for each user the connected-account email and display name of every extension they've authorized (Jira also records the Atlassian site the grant is pinned to). Extension tokens are never exported. If the group export fails, an org_groups.ERROR.txt is written rather than silently omitting it. Each messages.json entry carries:

• conversation_id, conversation_title
• message_id, role, content
• model_id, prompt_tokens, completion_tokens, total_tokens, elapsed_ms
• sql_queries (JSON, present for chat turns that ran SQL)
• metadata (JSON, free-form per-turn extras)
• created_at

Messages come from every storage tier — recent, archived and cold-stored — and are read without restoring anything, so an export never writes to your data. Conversations the user deleted are included, with deleted: true, until they are purged. analytics.json holds only that user's own figures (totals and a by-day timeline), never other members' rankings.

Each file holds one named section, for example { "conversations": [ … ] }. If one section cannot be read, its file holds { "error": "<Section> could not be read for this export." } instead, and the folder's export_info.json names it under incomplete_sections; a conversation whose messages could not be read is listed, with its title and why, under incomplete_conversations. Nothing is left silently empty. If gathering a specific user's data fails altogether, that user's folder gets an ERROR.txt and the rest of the export continues.

Running an export from the Users page

1. Open /admin/users.
2. Select rows with the checkboxes. The bulk bar appears at the bottom of the page.
3. Click Export data.
4. Confirm: "We'll email you a link to a ZIP archive of everything Strata keeps about each selected user; export_info.json in each folder lists every file. The link works only for you and expires 24 hours after it is sent. If the export fails, you will hear in your inbox and by email."

The request goes to POST /api/admin/export with { user_ids: [...] }, at most 200 people. More than 200 is refused before anything is sent (An export takes at most 200 people. Narrow the list, or export everyone from Organization data export.), unless the selection is everyone: Select all that match with no search and no filter, every one of them active, asks Export data for all N users? and posts { all: true }. The server answers at once (Export requested) and builds the ZIP in the background.

Running an export from the Organization page

1. Open Organization → Profile and scroll to the Account group at the bottom.
2. Click Export organization data…. Without canManageCompliance the row shows Needs the "Manage compliance" permission. Ask an owner. in place of the button.
3. Choose who to include. Everyone (every active member), Pick people (search by name or email and tick up to 200 people to include) or Everyone except (tick up to 200 people to leave out). Select all ticks the people shown, up to 200, and Deselect all clears your ticks; a line under the choice says how many are picked or left out, and the button names how many will be exported. Without the Manage users permission the export covers everyone, and the dialog says that picking members one by one needs it.
4. Pick the time range. The selector supports:
   • All time — every conversation regardless of age.
   • Last 30 days — conversations created in the last 30 days.
   • Last 90 days — conversations created in the last 90 days.
   • Custom range — date pickers for startDate and endDate in MM/DD/YYYY format.
5. Click Request export.

Everyone posts { all: true, range, … } and covers every active member (API service accounts are left out). Pick people posts the explicit user_ids; Everyone except posts { all: true, exclude_user_ids: [...] }. The same 24-hour link expiry and ZIP layout applies. The chosen range is recorded in manifest.json and bounds each user's conversations — and with them their messages, checklists, sub-agent tasks and the files attached to those conversations (files with no conversation, such as direct uploads, are always listed). analytics.json covers the same window: the 30- and 90-day presets as a rolling window, a Custom range by its start and end dates, and All time as the last ten years.

Safety caps and truncation

A single runaway export can't be allowed to exhaust the worker that also serves chat, agents, and voice. The background build streams data incrementally and stops at hard caps:

Nothing is ever silently dropped. If any cap is hit, the ZIP gets a TRUNCATION_NOTICE.txt listing what was capped, manifest.json gains a truncated: true flag with a truncation block, and each affected user's manifest entry carries its own truncated reason. To capture the omitted data, re-run in smaller batches (fewer users and/or a narrower date range).

How long does it take

For most organizations, the background build finishes in under a minute. Time scales with:

• Number of users.
• Number of conversations per user (capped at 10,000 per user; a cap that is reached is recorded in the folder's export_info.json).
• Number of messages per conversation.
• Range — narrower ranges build faster.

You will get the email when it is done. There is no in-app progress bar.

Email delivery

When the build finishes, Strata emails the requester that the export is ready. Delivery goes through Azure Communication Services (sendTransactionalEmail), so the deployment needs AZURE_COMM_CONNECTION_STRING and AZURE_COMM_SENDER configured. The link in the email works only for you: it opens while you are signed in to Strata with the permission that asked for the export (Manage compliance for an export of members), with Member chat oversight on, for 24 hours after the email is sent. Opening it hands your browser a read-only storage link to that one ZIP, good for five minutes. A link that no longer works takes you back to Users.

If the build fails, you get an inbox notice and an email saying it could not be completed and that nothing was sent; its Try again opens the page that runs that export. If only the email fails, the inbox notice says to run the export again for a new link. Your organization can have up to three exports building at once; a fourth is refused (Your organization already has 3 exports being built. Try again when one of them has arrived.).

If you do not receive the email within five minutes:

• Check your spam folder.
• Verify your organization's email is configured (AZURE_COMM_SENDER, AZURE_COMM_CONNECTION_STRING).
• Re-run the export.

How it differs from a per-user export

Each user's manage modal has an Export all data row on its Data & sessions tab, with an Email me button. It runs this same background job for that one member (POST /api/admin/export with one id in user_ids, across all time) and emails you the download link, as the Users page bulk action does; nothing downloads in the browser, so a large account doesn't run into the browser's time limit. It is meant for a single individual's offboarding or a GDPR data-subject-access request for one person, is gated by the same oversight switch and Manage compliance permission, and is logged as admin.users_exported like any other request here. A refusal is said under the row instead (oversight off, a missing permission, or too many bulk actions, the same per-admin limit of 20 per 5 minutes as deleting members and their chats), and any other failure reads "Couldn't request the export. Try again." For scripts, GET /api/admin/users/<userId>/export still returns one member's ZIP directly (strata-export-<name>-<yyyy-mm-dd>.zip), with the same files as one user's folder above, and is logged as user.data_exported with counts per section and any sections that could not be read.

The bulk admin export is the right tool for organizational backups, switching platforms, or producing a multi-user discovery package.

Audit trail

Each bulk admin export emits an admin.users_exported audit event. It is one of the events recorded at every tier, so it is written whatever your organization's audit detail level — a Standard-tier org records it too. The event carries details:

{
  "count": 47,
  "user_ids": ["…", "…"],
  "contentDisclosed": true,
  "scope": "selected_users_full_content",
  "range": "all"
}

For an all-users export, scope is all_users_full_content; for Everyone except, all_users_except_full_content, with the people left out in excluded_user_ids and their number in excludedCount. A per-user export is logged separately as user.data_exported. The exporter's email, IP, and timestamp are captured, so compliance teams can reconstruct who took what data, when, and under what oversight.

Storage and retention

The ZIP is uploaded to a private Azure Blob Storage container (data-exports) under a path like admin-exports/<orgId>/<timestamp>-strata-admin-export.zip. The emailed link is a Strata address, not a storage address; each time you open it, signed in, Strata issues a read-only storage link scoped to that exact blob that expires in five minutes.

After 24 hours the emailed link stops working. If you need the export again, re-run it to build a fresh ZIP and get a new link.

What can go wrong

See Users for per-user exports, Audit log for the export trail, and Organization deletion for the recommendation to export before deleting.

Related

• Organization
• Roles and permissions
• Audit log
• Organization deletion