Technical Deep Dive
OneTrust + Salesforce DSAR Fulfilment
Keep OneTrust as enterprise orchestration. Fulfil Salesforce erasure natively. Trigger Salesforce-side discovery and deletion via REST/API so the consumer is not bounced to an off-platform form.
Privacy Rights Automation completes the Salesforce data layer. OneTrust remains the enterprise governance plane. Your data never leaves Salesforce for fulfilment inside the org.
Hard scope: Requests enter Privacy Rights via UI, REST API, or integration with OneTrust, TrustArc, and MuleSoft. That is REST and complementary architecture — not a pre-built OneTrust connector, and not a shipped Service Cloud agent-on-call intake path.
The Privacy Rights Pipeline
From request intake to auditable proof of compliance
Request
Data subject submits a privacy request
A DSAR (Data Subject Access Request) or RTBF (Right to Be Forgotten) request arrives. Privacy Rights accepts requests via UI, REST API, or integration with OneTrust, TrustArc, and MuleSoft. Keep OneTrust as orchestration. Fulfil erasure inside Salesforce. Prefer API trigger so callers are not sent to a second off-platform form when identity is already captured. Do not describe Service Cloud agent-on-call as a shipped intake path.
Discovery
Graph engine finds every related record
After a request is accepted (UI or REST), input an email or customer ID. The graph engine discovers related records across Sales Cloud, Service Cloud, Marketing Cloud, and custom objects — without manual SOQL object-by-object. Service Cloud appears here as where related Cases and service history are found, not as the documented intake console for agents.
Review
Legal review and contract blocking
Before deletion executes, Privacy Rights checks business constraints. Running contracts block deletion in financial services scenarios. Legal review is built into the workflow.
- Inspect contract status before executing deletion on related Contacts
- Queue deletion requests when contracts are active; execute when contracts close
- Flag records under litigation hold for exemption from deletion
Execute
Cascade-aware deletion in safe batches
Deletions execute in governor-limit-safe batches. Master-Detail relationships are handled correctly. Related records across Cases, Contacts, Opportunities, and custom objects are deleted or anonymised in a single coordinated run.
Audit
360-degree audit trail generated
Every action is logged: what data was found, what was deleted, when, by whom, and under which regulation. The audit trail exports to PDF or CSV for regulator submission. Full chain of custody. No manual spreadsheets.
Call-center RTBF
Why call-center RTBF still dumps consumers onto a OneTrust form
Call centers often run Service Cloud while privacy orchestration lives in OneTrust. When a consumer asks for the right to be forgotten on the phone, many programs still refer them to a OneTrust web form instead of capturing the request where the agent already works.
That pattern shows up in the field: companies use a OneTrust form for RTBF on inbound calls and want Service Cloud to gather identity and move the request toward OneTrust via API (Reddit thread paraphrase — signal only, not consensus).
Copy gap (name it; do not invent a fix as shipped): Live Cloud Compliance copy documents OneTrust → Salesforce / Privacy Rights fulfilment (portal or privacy-suite intake into Salesforce-native discovery and deletion). The call-center ask is the reverse direction at intake: Service Cloud agent on the call → push into OneTrust. Public CC materials do not document a shipped agent-on-call click-path. Until then, describe intake as UI or REST only.
Service Cloud in live Privacy Rights copy is a discovery surface (records found across Service Cloud objects) — not documented as the intake UX for agent-on-call capture.
Integration directions
Two integration directions
| Direction | What it means | What live CC copy supports |
|---|---|---|
| OneTrust → Salesforce | Privacy portal / suite creates or triggers a request; Salesforce fulfils discovery, erasure, portability, audit | Documented: UI / REST / OneTrust·TrustArc·MuleSoft integration; Floor & Decor portal→ESB→CC REST/Invocable; datasheet privacy-suite intake |
| Salesforce intake → OneTrust / fulfilment | Agent or Case captures the request in Salesforce, then notifies or syncs orchestration | Partial: datasheet allows bidirectional REST (trigger + completion). Agent-on-call → create in OneTrust is the named gap — not a shipped CC claim |
OneTrust documents its own Service Cloud DSR pattern via Email-to-Case (web form → confirmation email → Salesforce Case with Request ID; closing the Case can API-close in OneTrust) and Salesforce Contact deletion via Connected App + OAuth + gallery workflow. Those are OneTrust product docs — useful architecture references, not CC feature claims.
A community commenter pointed at the OneTrust Salesforce integration page and the OneTrust API reference and called Salesforce+OneTrust “relatively common.” Cite as a community pointer only — not product proof of any CC connector.
Request packet
What Service Cloud should capture on the call (identity, request type, proof)
Whether intake is a privacy-suite form or a future agent workflow, the fulfilment engine still needs a complete request packet. Capture at least:
| Field | Why |
|---|---|
| Identity keys | Email, customer ID, or other verified subject identifiers graph discovery can search |
| Request type | RTBF / erasure, access, portability, correction — maps to GDPR Art. 17 / Art. 12 definitions and CCPA delete/know/portability |
| Proof / verification status | What identity proof was collected; who verified; when |
| Regulation / jurisdiction | Which response clock and scope rules apply |
| Channel + agent Case ID | Traceability from the phone interaction to the privacy ticket (Case linkage is a datasheet pattern for suite intake — not an agent-on-call product claim) |
Do not bounce the consumer to a second form if the agent already has this packet — push it into the orchestration and fulfilment path via API instead.
Layer ownership
Where OneTrust stays vs where Salesforce-native fulfilment must run
| Layer | Owner | Role |
|---|---|---|
| Enterprise orchestration | OneTrust (or TrustArc) | Intake portals, cross-system DSR tracking, preference/consent programs, enterprise governance |
| Salesforce data layer | Privacy Rights Automation | Graph discovery, cascade-aware deletion/anonymisation, contract blocking, portability export, Salesforce-native audit |
| Middleware (optional) | ESB / MuleSoft | Route portal events to Salesforce REST/Invocable endpoints |
Complementary positioning only: CC = Salesforce data layer; OneTrust = enterprise orchestration. No vs-OneTrust framing. No claim of a certified or pre-built OneTrust connector — live language is REST / rich APIs and complementary integration (AppExchange listing; Pricing — “Integrate Onetrust, Securiti.ai & others”).
Name OneTrust, TrustArc, and MuleSoft only on this page (live triad).
External platforms fulfil by calling Salesforce over API. Personal data crossing the org boundary during that call is a DPIA question — see Salesforce Privacy Center alternatives.
After intake
Graph discovery across Sales / Service / Marketing Cloud after intake
After a request is accepted (UI or REST), input an email or customer ID. The graph engine discovers related records across Sales Cloud, Service Cloud, Marketing Cloud, and custom objects — without manual SOQL object-by-object.
Service Cloud appears here as where related Cases and service history are found, not as the documented intake console for agents.
Floor & Decor (retail): OneTrust Privacy Portal → Enterprise Service Bus → Cloud Compliance REST/Invocable APIs for CCPA portability and erasure (case study). Direction is portal → CC, not agent → OneTrust.
Fulfilment depth
Cascade, contract blocking, and audit proof the agent's Case cannot finish manually
An agent Case can record the ask. It cannot safely finish Salesforce erasure by hand when:
- Related records span Leads, Contacts, Accounts, Cases, Opportunities, Contracts, Marketing Cloud, and custom objects
- Master-Detail and cascade order must be respected
- Active contracts must block deletion until close (financial-services pattern)
- Litigation holds must freeze records
- Auditors need proof of what was found, what was deleted or anonymised, when, by whom, and under which rule
Privacy Rights runs cascade-aware deletion in governor-limit-safe batches, applies contract blocking, and writes a 360-degree audit trail exportable to PDF or CSV. That is the Salesforce fulfilment layer the Case cannot complete manually.
Build vs buy
Build (Email-to-Case + Apex) vs AppExchange Privacy Rights + OneTrust API
| Approach | Intake | Fulfilment | Audit | Fit |
|---|---|---|---|---|
| Email-to-Case + custom Apex | OneTrust form → email → SF Case (OneTrust-documented pattern) | Hand-built discovery, cascade, governors | Spreadsheets / custom logs | Small scope, high eng ownership |
| Privacy suite + Privacy Rights REST | OneTrust/TrustArc portal or suite → REST/Invocable (optionally via ESB/MuleSoft); datasheet: auto-creates Case in Salesforce | Graph discovery + cascade + contract blocking inside Salesforce | Native Salesforce audit trail; completion notifications via REST | Salesforce is system of record for CRM personal data |
| Agent-on-call → OneTrust create | Desired by some Service Cloud teams | Depends on OneTrust API + SF capture | Depends on build | Named gap — not a shipped CC click-path |
Datasheet RTBF/Portability (live): request enters via web form, email, or privacy suite (OneTrust, etc.); auto-creates a Case in Salesforce; REST APIs enable bidirectional integration with OneTrust, TrustArc, ServiceNow, or custom portals — trigger Salesforce workflows from external requests and connect completion back. Closest live “Case in Service Cloud” copy. Still suite-as-intake, not agent-on-call. See RTBF/Portability datasheet.
Multi-org portal fan-in (secondary): Multi-Org Privacy and Security Hub already covers OneTrust/Osano/home-grown portals via REST — see Multi-Org Privacy and Security Hub.
Under the Hood
What Privacy Rights does in each phase
Graph-based discovery across all Clouds
After a request is accepted (UI or REST), input an email or customer ID. The graph engine discovers related records across Sales Cloud, Service Cloud, Marketing Cloud, and custom objects — without manual SOQL object-by-object. Service Cloud is a discovery surface (related Cases and service history), not the documented intake UX for agent-on-call capture.
Manual DSAR processing requires querying objects one by one across Sales, Service, and Marketing Clouds. Privacy Rights automates the discovery step completely: no missed data, no manual effort. Floor & Decor used OneTrust Privacy Portal → Enterprise Service Bus → Cloud Compliance REST/Invocable APIs for CCPA portability and erasure — portal → CC, not agent → OneTrust.
Cascade-aware deletion with contract blocking
Safe deletion that respects Salesforce's relational integrity. Master-Detail relationships are handled correctly. In financial services (loan, revolving credit, insurance contracts), deletion is blocked while the contract is active. Privacy Rights inspects the contract status before executing deletion.
If a contract exists, deletion is held in queue until the contract closes. This prevents deleting records the law says you cannot touch while a business relationship is active. Litigation holds freeze records. Auditors need proof of what was found, deleted or anonymised, when, by whom, and under which rule.
Governor-limit-safe batch processing
Large DSAR requests (500K+ records) execute in safe batches without hitting Salesforce DML limits (10K rows). Deletion completes reliably. Progress is tracked. No manual intervention required during bulk delete.
Manual deletion creates cascade problems: delete a Contact and you might accidentally delete Cases or Opportunities attached to it. Privacy Rights handles the ordering and batching to prevent data loss.
Data portability export
CCPA requires portable data in machine-readable format. GDPR Article 20 requires the right to data portability. Privacy Rights generates formatted data exports automatically for the data subject, covering all discovered records across objects.
No external tools required. The export is generated from the same discovery graph used for deletion, ensuring consistency between what was found and what is provided to the data subject.
360-degree audit trail for every request
Privacy Rights creates a comprehensive audit trail: what data was found (timestamp, object, field count), what was deleted (Contact ID, related Cases, Contracts), deletion success or failure, executed by (user), and approval chain if required.
The log exports to PDF or CSV for regulator submission. Auditors get proof of compliance. Internal audit reviews have concrete evidence. No 'we think we deleted it' uncertainty.
Architecture
100% inside your Salesforce org
Privacy Rights Automation is a managed package. Every component (discovery UI, deletion engine, and audit trail) runs inside your Salesforce org as native Apex. No external infrastructure. No data leaves your environment.
Salesforce Org
Privacy Rights Managed Package
Request Intake & Discovery UI
Lightning / Visualforce
Accept DSAR/RTBF requests via UI or REST API. Graph-based discovery visualises all related records before deletion. Legal review workflow built in.
Graph Engine & Business Rules
Custom Objects + Custom Settings
Object relationship graph, contract blocking rules, litigation hold flags, and deadline tracking stored natively in Salesforce Custom Objects.
Deletion Engine + Audit Trail
Apex Batch Processing
All deletion execution, cascade handling, portability export, and audit logging runs as managed Apex code within your org. No external compute. No outbound data movement.
Graph engine traces object relationships automatically: no manual SOQL required for discovery across Sales, Service, and Marketing Clouds
REST API endpoints enable complementary integration with OneTrust, TrustArc, MuleSoft, and any enterprise privacy platform
Hub-and-spoke orchestration supports multi-org privacy rights workflows from a single management console
Technical Specifications
Request types
DSAR, RTBF, Data Portability, Correction
Discovery method
Graph-based: automatic across all Clouds
GDPR deadline
30-day response: met consistently
CCPA deadline
45-day response: met consistently
HIPAA deadline
60-day response: met consistently
Cascade handling
Master-Detail + contract blocking
Bulk processing
500K+ records in governor-safe batches
Cost savings
$1,400+ per request vs manual processing
Integration
REST API: OneTrust, TrustArc, MuleSoft
Multi-org
Hub-and-spoke orchestration supported
Deployment method
Managed package via AppExchange
Release quality
107 regression tests, 240 hours testing per release
Compare
Privacy Rights vs the Alternatives
Manual processing and ad hoc tooling struggle at volume. See the operational and audit differences in one place.
Frequently Asked Questions
See Privacy Rights process a DSAR in 1 click
30-minute technical demo. We show you graph-based discovery, cascade-aware deletion, contract blocking, and the 360-degree audit trail on a real Salesforce org.