Email storage & privacy (GDPR)
What email data Workestra stores when you connect a mailbox, where it lives, how it's protected, and how to exercise your data subject rights.
Email storage & privacy
When you connect a Gmail or Microsoft 365 mailbox to Workestra, your email content is synced into Workestra's database. This page tells you exactly what we store, where, and how it's treated for privacy purposes.
If you're the workspace admin, this is the reference you need when answering "what happens to our mail once we connect it?" from your legal team, IT, or customers.
What Workestra stores
| Data | Stored? | Where |
|---|---|---|
| Email body (HTML + plain text) | Yes | synced_emails.body_html, synced_emails.body_text |
| Subject, sender, recipients | Yes | synced_emails.subject, from_address, to_addresses, cc_addresses, bcc_addresses |
| Sent / received timestamps | Yes | synced_emails.sent_at, received_at |
| Message raw headers | Yes (JSON) | synced_emails.raw_headers |
| Attachment metadata (filename, size, MIME type) | Yes | synced_emails.has_attachments, attachment_count |
| Attachment binary content | No | — click-through to the provider to download |
| Drafts | No | Filtered out at ingest |
| Folders other than Inbox and Sent | No | Archive, custom labels, sub-folders not synced |
| Your mailbox password | No (ever) | OAuth only |
| OAuth access & refresh tokens | Yes (encrypted) | user_email_connections.access_token, refresh_token — AES-256-GCM at rest |
Where it lives
- Primary storage: your Supabase Postgres database. Workestra doesn't run its own email storage infrastructure — it sits on top of Supabase, which uses standard cloud providers with volume-level encryption at rest and TLS in transit.
- Region: set at the Supabase project level. Ask your Workestra admin (or check Supabase dashboard → Project Settings → General → Region) to confirm the region your tenant is in. EU customers should use an EU region; switching later is a migration, not a setting.
Sub-processors
Workestra relies on these third parties to deliver the email integration:
| Sub-processor | Role | Data processed |
|---|---|---|
| Supabase | Database + realtime | All email content at rest + in transit |
| Microsoft (Graph API) | OAuth provider, source of Outlook / 365 mail | OAuth flow + ongoing message reads |
| Google (Gmail API) | OAuth provider, source of Gmail mail | OAuth flow + ongoing message reads |
| Vercel | Compute layer (serverless functions) | Processes email content in-memory; nothing persisted outside Supabase |
| Resend | Outgoing workspace email | Only for send-as-workspace emails, NOT for connected mailbox traffic |
| Sentry | Error monitoring | Error context only — email bodies are scrubbed from error logs |
Each sub-processor has its own privacy policy and certifications. Workestra's Data Processing Agreement should reference the current list.
Encryption
- In transit: TLS 1.2+ for every API call (Graph, Gmail, Supabase, webhooks).
- At rest — OAuth tokens: AES-256-GCM, encrypted application-side before storing. Even a full database dump can't be used to impersonate users.
- At rest — email bodies: protected by Supabase's volume-level encryption. Not additionally encrypted application-side. This matches the industry norm for "email content at rest" but is less strict than some regulated verticals (health, legal, finance) require.
If your compliance framework mandates field-level encryption of email content, contact us — it's not the default but can be enabled per workspace.
Access control
- Workspace isolation: every
synced_emailsrow carries aworkspace_id. Row-Level Security (RLS) restricts reads to workspace members. A user in workspace A cannot see emails from workspace B even if they share the same counterparty address. - Connection ownership: each mailbox is owned by a specific user. Shared mailboxes (see Shared Mailboxes) are delegated — they inherit access from the owning user's Exchange permissions.
- Internal access: Workestra staff access your data only when you file a support ticket and explicitly grant access, or for security incidents under our incident-response runbook. Access is logged.
Retention
There is currently no automatic deletion of synced email. Mail accumulates in synced_emails until:
- You disconnect the mailbox (retains data by default — the connection is removed but messages stay so your CRM history remains intact).
- You exercise your right to erasure (see below).
- Your workspace is deleted (cascades to every email linked to it).
For most sales and support workflows, this is what you want — a 3-year-old email thread with a customer is still useful context. If your organization has a stricter retention policy (e.g. "delete all email older than 12 months"), contact us. A workspace-level retention setting is on the roadmap.
Your data subject rights (GDPR Articles 15-22)
Workestra is a processor for the email content you bring from Gmail / Microsoft 365. Your company (as the workspace admin) is the controller. This means primary responsibility for honouring data subject requests lies with your company — Workestra provides the tools.
Right of access (Art. 15) — export
Every workspace member can request an export of their own personal data:
- Settings → Profile → Privacy → Export my data, or
POST /api/gdpr/exportwith your session token
The exported JSON includes your CRM records, activities, and profile data.
Current gap: the export does NOT yet include synced_emails or user_email_connections. This is a known limitation and on the roadmap. In the interim, if you receive a subject access request that must include email, contact support — we can produce a per-user email extract on demand.
Right to erasure (Art. 17) — delete
Similar endpoint: POST /api/gdpr/delete. Confirms deletion of your CRM data, activities, and auth user.
Same gap: the delete endpoint does NOT yet purge synced_emails for the requesting user. To fully honour an erasure request today:
- The user disconnects the mailbox (Settings → Integrations → Outlook → Trash).
- An admin runs the following SQL on Supabase (or opens a support ticket asking us to run it):
delete from synced_emails where connection_id in (
select id from user_email_connections where user_id = :user_id
);
delete from user_email_connections where user_id = :user_id;Right to restrict processing (Art. 18)
Pause sync on any connection: Settings → Integrations → Outlook → the mailbox → Pause sync. Existing data is retained but no new email is pulled.
Right to rectification (Art. 16)
Synced emails are a copy of what's in your provider. To correct them, correct them at the source (Outlook / Gmail) — the next sync pulls the corrected version. Workestra doesn't expose an in-UI edit for synced-email content on purpose: editing the copy would create a divergence from your mailbox of record.
Right to data portability (Art. 20)
The export endpoint (see Art. 15) produces JSON. For email content specifically, the authoritative portable copy is your Outlook / Gmail mailbox — not Workestra's sync of it.
Disclosure for DPAs
Workestra sits on the following flow when handling customer email:
User's mailbox (Microsoft 365 / Gmail)
│
▼
Microsoft Graph / Gmail API
│
▼
Workestra (Vercel serverless compute)
│
▼
Supabase Postgres (encrypted at rest)
│
├──► Workestra UI (TLS 1.2+, RLS-enforced)
└──► Workestra internal AI (on explicit user opt-in only)Copy this into your DPA appendix and adjust region / sub-processor names to match your Workestra plan's infrastructure.
What Workestra's internal AI sees
If you've enabled AI features in Settings → AI (off by default for new workspaces), the AI engine may read email content when you:
- Summarise a contact / deal / ticket / candidate
- Draft an AI-generated reply
- Ask the AI chat panel about a specific conversation
The AI call uses your workspace's configured provider (OpenAI by default, configurable). The content is NOT used to train those providers' models — we set user / workspace_id tenant scoping on every call per the provider's enterprise policy. If you need zero-retention guarantees (enterprise tier with OpenAI or Anthropic), contact us to route to a zero-retention endpoint.
AI features can be disabled entirely by the workspace admin at any time. When disabled, email content is never sent to a third-party LLM.
FAQ
Q: Is my email physically leaving Microsoft / Google's servers? A: Yes — Workestra fetches message content via Microsoft Graph / Gmail API and stores it in Supabase. This is the necessary trade-off for the CRM-integrated workflow (threads on contact pages, cross-mailbox search, etc.). If you need your mail to stay inside Microsoft / Google infrastructure only, don't connect a mailbox to Workestra.
Q: Can I tell Workestra to only sync mail from specific contacts? A: Not today. All inbound mail in the chosen backfill range + all new mail is synced once a mailbox is connected. A selective sync filter is on the roadmap.
Q: What happens if I disconnect? A: The connection row is deleted, the OAuth token is invalidated, no new mail syncs. Previously synced messages are retained so your CRM history stays intact. If you want them gone too, follow the erasure SQL above or open a support ticket.
Q: Can Workestra staff read my email? A: Not in the course of normal operations. Staff access requires a signed incident ticket or your explicit support-access grant, and every access is logged in our audit trail.
Q: How do I answer "is Workestra GDPR-compliant" when a prospect asks? A: Accurately: Workestra is GDPR-friendly by design (processor role, workspace isolation, encryption at rest, exportable data). There are two known gaps above (export / delete don't yet cover synced_emails) which we treat on a workspace-by-workspace basis until the automated flow is shipped. Don't claim "fully GDPR-compliant" until those gaps are closed.
Next Steps
- Historical backfill — how mail gets pulled in
- Microsoft 365 Integration — OAuth and scopes
- Shared Mailboxes — team-access mailboxes
- Email in your modules — where mail surfaces across Workestra