1. Overview
The Salesforce integration uses a customer-managed Connected App or External Client App and OAuth client-credentials flow with a dedicated execution user.
Seedling reads a configured population of CRM objects and their field metadata. The Salesforce organization ID is the provider account identity; an organization label or instance hostname is not a substitute.
2. Connection and scope
Seedling verifies the provider account before storing the connection. A personal connection remains actor-owned; a workspace connection is administered for the selected Seedling workspace. Credentials are never inferred from an email address or silently promoted between scopes.
- OAuth client credentials
- The customer enables client credentials, selects a dedicated API-only execution user, and supplies the app client ID and secret. Login URL, instance URL, API version, and organization name may be configured.
- Personal or workspace connection
- Every API request is bounded by the execution user's object permissions, field-level security, sharing access, and the app's api OAuth scope.
3. Salesforce data Seedling accesses
Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.
- Default CRM objects
- Accounts, Contacts, Leads, Opportunities, Cases, Tasks, and Events visible to the execution user, including deleted-record windows used for synchronization.
- Schema
- Object descriptions, fields, field types, relationships, labels, and selected custom-object or custom-field metadata.
- Security context
- Available users, groups, roles, permission sets, object permissions, and field permissions used to interpret access conservatively.
4. Read-only permission contract
Salesforce's api OAuth scope permits API use; the dedicated execution user's profile, permission sets, sharing, and field-level security must supply the actual read boundary.
- OAuth scope api — use Salesforce REST APIs.
- API Only User — prevent ordinary interactive use for the dedicated execution identity.
- Read access only for selected CRM objects and indexed fields.
- Optional read access to User, Group, UserRole, PermissionSet, ObjectPermissions, and FieldPermissions for safer security interpretation.
- Avoid View All Data unless the intended Seedling workspace should index that entire provider-visible population.
5. Security and access
- Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
- Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
- The provider does not expose enough object-level audience evidence for Seedling to reproduce every native permission safely. Workspace content therefore follows the connection's restricted-by-default policy; administrators and stewards receive no raw-content bypass.
- Personal-connection raw content remains visible only to the connecting member in human-facing Seedling surfaces.
- Salesforce object access, field-level security, record sharing, roles, territories, queues, and teams can differ. Missing or ambiguous security evidence never grants a human audience.
- Generated output cannot bypass Seedling's human review, verification, and approval gates.
6. Retention and deletion
- Connected data
- Synchronized Salesforce records remain while the connection is active and are removed through a durable integration purge after disconnect.
- Credentials
- Stored Salesforce credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
- Backups
- Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.