Salesforce
Data Residency and PII
Salesforce is the only durable home for personal data in a Forge deployment. This page explains exactly what is stored where, for how long, and what Forge guarantees about personal information.
PII policy — non-negotiable
Names, email addresses, phone numbers, and postal addresses are never written to Forge's Postgres database. They are fetched from Salesforce just-in-time, may be held briefly in an encrypted Redis cache, and then evicted. No exceptions exist to this rule.
What counts as PII
| Data type | PII? | Where it lives |
|---|---|---|
| Person name (first, last, full) | Yes | Salesforce Contact, Lead, or Attendee__c only |
| Email address | Yes | Salesforce Contact, Lead, or Attendee__c only |
| Phone number | Yes | Salesforce Contact or Lead only |
| Postal address (street, city, state, postal code) | Yes | Salesforce Contact or Lead only |
| Salesforce record IDs | No | Postgres (audience snapshots, audit logs, session keys) |
| Counts and aggregates | No | Postgres and Redis (no individual-level data) |
| Timestamps and event durations | No | Postgres (audit logs, scheduler jobs) |
| Feature flags and settings | No | Postgres or Redis |
| Email templates (HTML with merge tokens) | No | Postgres (merge values fetched JIT from Salesforce at send time) |
| B2B company/account names | No | Postgres (audience segment members table stores account_name only) |
Storage and handling by system
| System | What it stores | How long |
|---|---|---|
| Salesforce | All customer records: Events, Attendees, Contacts, Leads, Forms, Answers, Transactions, Speakers, Sponsors | Indefinitely — your org controls retention |
| Forge Postgres | Tenant rows; user rows (Forge internal staff email + Salesforce User ID); encrypted OAuth refresh tokens; sessions; audience snapshot definitions; ID-only audience member sets; email job definitions; audit logs; object mapping metadata | Tenant data: until org disconnected. Audit logs: 90 days. |
| Redis (optional) | Attendee display names and email (encrypted, cache key = tenantId + eventId); describe metadata; feature flags; picklist values | Attendee data: 2 hours then auto-evicted. Other entries: 1–60 minutes. |
| Forge logs | Org ID, Salesforce record IDs, error codes, HTTP status | 30 days — PII is redacted before any log entry is written |
| Email provider (SendGrid) | Recipient email address during delivery; suppression list | Short-lived during delivery only. Suppression list: email address only, for bounce/unsubscribe management. |
Scenario: attendee list
When a planner opens the Attendees tab for *Planner Conference 2026, Forge checks Redis for a cached list. If a warm entry exists (under 2 hours old), it is returned directly. If not, Forge queries conference360__Attendee__c in Salesforce, hydrates the result, writes it to Redis with a 2-hour TTL, and returns it to the browser. The attendee names and emails are never written to Postgres.
Scenario: registration form submission
When an attendee submits a registration form on the public event page, Forge validates the answers in memory and writes them directly to Salesforce (conference360__Form_Submission__c and conference360__Form_Submission_Answer__c). Form answers that map to Contact or Lead fields (name, email, phone) are written to those standard objects in Salesforce. No PII is written to Forge's Postgres at any point during registration.
Checkout cache exception
During the registration checkout flow, in-progress registration data (including the registrant's name and email) is held in an encrypted short-lived checkout cache for approximately 20 minutes while the payment is processed. This cache is encrypted and never written to Postgres. It is discarded immediately after the transaction completes or times out.
Scenario: email campaign send
Email send jobs store only the Salesforce IDs of recipients (Contact, Lead, or Attendee records) in Forge's Postgres. When the job executes, Forge fetches the email addresses just-in-time from Salesforce, streams the send through the email provider, and discards the addresses. No recipient email list is ever written to Postgres.
Scenario: data export
Exports (CSV downloads of attendees, registrations, or reports) are streamed directly from Salesforce through Forge to the browser. The export data is never written to Forge's storage systems — not to Postgres, not to Redis, not to disk.
Audience segments and ID-only snapshots
Audience segments in Forge represent a SOQL filter expression (for example, 'all Registered attendees from Events in 2025'). When a segment is materialised for use in an email campaign, Forge writes only the Salesforce IDs (sf_id) of the matching records to the audience_segment_members table — no names, no email addresses, no phone numbers. PII is fetched from Salesforce at job execution time.
Beacon (AI copilot) — data handling
| Data type | How Beacon handles it |
|---|---|
| Salesforce records queried during a session | Queried live per request — never bulk-synced or stored outside Salesforce. |
| Conversation history | Moving to your Salesforce org before general availability. Email and phone numbers are pseudonymized wherever conversation data is processed outside Salesforce. |
| Knowledge base | Contains only Blackthorn product and help content — no customer personal data. |
| Cross-customer isolation | Each Salesforce org is fully isolated; no cross-customer data sharing or AI training on customer data. |
Cache contract
- Salesforce org ID + record IDs are the primary cache key components — no cross-tenant data leakage is structurally possible.
- Attendee name and email are cached for up to 2 hours under keys scoped to tenantId and eventId. These entries are auto-evicted by Redis TTL and never promoted to Postgres.
- If Redis is unavailable, Forge falls back to a short-lived in-process cache with the same TTLs. No data is lost or leaked on Redis failure.
- The sf_write_outbox table (used for SF write-through jobs) has its payload column set to an empty JSON object the moment a row transitions to done or dead. A 2-hour reaper job deletes finalised rows, so PII never lingers beyond the same window as the Redis cache.
Data deletion and export requests
Because Forge holds only Salesforce IDs and non-PII operational state, a data deletion request is satisfied by deleting the records in Salesforce (which are the sole durable store of personal data). Forge's Postgres rows that reference a deleted org are purged when the tenant disconnects. Contact your Blackthorn support rep if you need a written data-processing agreement.