This category touches your CRM, so we keep the boundary simple: we read metadata — object and field definitions — and nothing else. We’re read-only by default; the only thing we ever write back is a field description you explicitly choose to push.
Object and field definitions, picklists, relationships, descriptions, and configuration metadata. The one write we can make is filling an empty field description — only when you explicitly confirm it.
The contents of your records. We never read, store, or transmit your actual Salesforce data. PII detection works entirely on field names, labels, and types — never on values.
You connect via Salesforce’s External Client App OAuth pattern and approve the scopes. You can disconnect at any time, which revokes our access immediately.
Salesforce tokens are encrypted at rest and scoped to the worker that needs them. Tenant data is isolated by row-level security, and we never put tokens, org IDs, or personal data in URLs.
We use a small set of trusted infrastructure providers. None of them receive the contents of your Salesforce records.
| Subprocessor | Purpose | Region |
|---|---|---|
| Supabase | Database, auth & storage | US |
| Vercel | Application hosting & edge | US |
| Anthropic | Assistant language generation (schema context only) | US |
| OpenAI | Semantic search & metadata enrichment | US |
| Stripe | Billing & payments | US |
| WorkOS | Authentication, SSO & directory sync | US |
| Resend | Service & notification email | US |
| PostHog | Product analytics | US |
| Optional Sheets/Drive export (drive.file) | US |
The Data Processing Agreement covers our processing commitments in full.
We’re honest about where we are: SchemaForce is built metadata-only with encryption at rest and tenant isolation from day one. SOC 2 readiness is on our roadmap as we move up-market. We don’t display badges we haven’t earned.