AgentFlow Enterprise Docs
Supabase Schema & RLS Overview
Tenant data is scoped to organizations and active memberships. Browser access is narrower than service-role backend access.
Tenant Model
| Table | Purpose |
|---|---|
organizations | Top-level tenant/company/workspace container. |
organization_members | Maps Supabase Auth users to organizations with role and active/invited/suspended status. |
workspaces | Workspace rows nested under organizations. The server creates a default workspace when needed. |
profiles | User profile records tied to Supabase Auth users. |
The central RLS rule is: authenticated users can access customer-facing tenant rows only when those rows belong to an organization where the user has an active membership.
Core Product and Billing Tables
| Table | Notes |
|---|---|
leads | Lead capture and AI qualification summary fields. Browser select/insert/update are organization-scoped; no authenticated delete grant is documented. |
lead_qualifications | Historical AI qualification outcomes. Insert checks require matching organization, workspace, and lead. |
subscriptions | Stripe-managed subscription state. Browser reads are limited to safe status fields by grants. |
checkout_sessions | Stripe/PayPal checkout session records. Browser reads are limited to status metadata, not checkout URLs or provider internals. |
usage_counters | Monthly plan usage counters for leads, AI qualifications, API requests, integrations, members, and workspaces. |
usage_events | Legacy/operational usage event stream. Hardened migration revokes authenticated access for normal operations. |
audit_events | Tenant-scoped audit event metadata for relevant actions. |
audit_logs | Legacy/operational audit table treated as service-role-only in hardened docs. |
api_keys | API key metadata and hashes. Authenticated reads are metadata-only for admin members; key_hash is not browser-granted. |
integration_connections | Integration provider status and non-secret metadata. Secret config fields are not browser-granted. |
billing_events | Stripe webhook event payload and processing state. Operational/provider payload table. |
Lead Access Rules
| Operation | Current documented behavior |
|---|---|
SELECT | Allowed for authenticated users in active member organizations. |
INSERT | Allowed for authenticated users with write-capable organization roles and matching workspace organization. |
UPDATE | Allowed for write-capable members in the same organization; organization_id is not included in browser update grants. |
DELETE | No authenticated delete policy/grant is documented in the hardened RLS summary. Use reviewed server-side or operator workflows for retention/deletion. |
Billing and Service-Role Boundaries
Browser clients can read safe subscription and checkout status columns. Stripe customer ids, provider session ids, checkout URLs, webhook payloads, provider internals, API key hashes, integration secrets, and raw operational metadata are server-managed.
- Service-role-only or operational tables include
billing_events,integration_events,hubspot_webhook_events,implementation_requests,usage_events, andaudit_logs. - Provider payloads and API key hashes must not be surfaced to the browser.
- RLS must not be disabled to debug tenant issues. Use non-production data and the manual tenant isolation checklist.
- Source RLS reference: docs/security/supabase-rls-tenant-isolation.md.
These docs describe implementation readiness and configuration. They are not a SOC 2, ISO 27001, penetration test, or contractual SLA claim.