How to Automate DSAR Fulfilment in Salesforce, End to End

Automating DSAR fulfilment in Salesforce means turning six manual steps into one workflow: accept the request, verify identity and fix its scope, discover every record about that person across all objects, decide what to delete, anonymise or export, execute without breaking related records, and produce an audit trail a regulator will accept. Cloud Compliance's Privacy Rights Automation does this natively in your org. This article walks through each step — what it requires, where manual handling fails, and what the automated version actually does.

What a data subject request requires of a Salesforce org

Under GDPR, a person can ask for a copy of their data (Article 15), its erasure (Article 17), or a portable export (Article 20). Under CCPA/CPRA the equivalents are the rights to know, delete, correct and port. HIPAA gives patients a right of access to their records. The wording differs; the operational shape does not. Somebody has to find every record that relates to one human being, decide what the law lets you do with each, do it, and prove you did.

The clock starts when a valid request lands, and it runs on you:

The full, sourced table is on the Privacy Rights Automation page. Note the phrase that matters: one month, not thirty days, under GDPR — and identity verification does not pause the clock everywhere.

Why the manual version fails

Salesforce has no native DSAR workflow. There is no button that finds everything about a person, no cascade-aware delete that knows a running contract is attached, and no audit log shaped for a supervisory authority.

So the manual process looks like this. A request arrives by email or through a privacy portal. Someone raises a ticket. An admin queries Leads, Contacts, Users, Cases, Opportunities and however many custom objects the org has accumulated — one SOQL query at a time. Legal reviews a spreadsheet. Someone builds a CSV. It goes out by secure email, and the spreadsheet becomes the audit trail.

It fails in three predictable places:

Discovery is incomplete. Object-by-object querying misses Marketing Cloud, custom objects, and related records nobody remembered. The manual-vs-automated comparison on our site puts it plainly: easy to miss Marketing Cloud, custom objects, or related records. An erasure that leaves a copy behind is not an erasure.

Deletion cascades the wrong way. Delete a Contact and Salesforce may take Cases and Opportunities with it. If that Contact has a running contract, you have just deleted records the law requires you to keep. If it is under litigation hold, worse. Manual deletion does not stop to check.

Proof does not exist. An email thread and a spreadsheet rarely satisfy a regulator who asks for the complete chain of custody: what did you find, what did you do to each record, when, and on whose authority.

And it is expensive. Gartner's widely cited estimate — relayed by Captain Compliance in DSAR Cost: How Much Does Each Cost? — puts the fully loaded cost of a manually processed request at $1,524, almost all of it labour. At forty or fifty requests a month — the volume at which the teams we work with say manual handling becomes unsustainable — that is a full-time function doing work that should take minutes.

Step 1 — Intake: accept the request where it already is

The request has to enter a system that can act on it, with the identity and request type attached. Privacy Rights Automation accepts requests through its own UI, through a REST API, and by integration with privacy-orchestration suites — OneTrust, TrustArc and MuleSoft — over REST and Invocable APIs.

The design principle: if your privacy portal or your suite has already captured identity and request type, push the request into Salesforce by API. Do not bounce the consumer to a second form. Floor & Decor's implementation is the reference pattern — requests originate in a OneTrust privacy portal, pass through enterprise service-bus middleware, and trigger Cloud Compliance's REST and Invocable APIs inside Salesforce for portability and erasure. The case study describes the architecture.

One honesty note: this is REST integration, not a pre-built OneTrust connector. The suite stays the orchestration plane; Salesforce-native fulfilment is what runs underneath it.

Step 2 — Scope: verify identity, name the regulation, start the right clock

Before anything is discovered or deleted, the request packet needs four things: a verified identifier the discovery engine can search (email address, customer ID), the request type mapped to a right (access, erasure, portability, correction), the regulation and therefore the deadline that applies, and any reason the request cannot be fully honoured — an active contract, a legal hold, a retention obligation.

Automation does not make the identity-verification judgement for you, and it should not. What it does is record who verified, when, and under which regulation the request is being handled — so the audit trail starts at intake, not at deletion.

Step 3 — Discovery: one identifier, every related record

This is the step that decides whether the response is complete. Privacy Rights Automation takes a single identifier and uses a graph engine to trace every related record across Sales Cloud, Service Cloud, Marketing Cloud and custom objects — following relationships rather than querying objects one at a time. No SOQL to write, no list of objects to remember.

The output is the discovery result: objects and record counts tied to the data subject. That result is itself logged, because "what did you find" is the first question a regulator asks.

Step 4 — Decision: delete, anonymise, export — and when to refuse

Not every record found should be deleted, and erasure is not the only right. Three decisions happen here.

Which records are legally in scope. Before deletion executes, Privacy Rights checks business constraints: a running contract on a Contact blocks deletion (the financial-services case), records under litigation hold are flagged for exemption, and requests can be queued to execute when a contract closes. Legal review is a step in the workflow, not an email outside it.

Delete or anonymise. Some records must go; some must stay for a retention obligation but no longer identify the person. Anonymisation keeps the record and its relationships and removes the identity. The Data Retention side of this — how long you keep what — is the mirror image of erasure, and the two should be configured together.

Access and portability. For an access or portability request the output is an export in a machine-readable format — PDF, CSV or JSON — assembled from the discovery result. CCPA requires portable data in a machine-readable form; GDPR Article 20 says the same for data the person provided.

Step 5 — Execution: cascade-aware, in batches Salesforce can handle

Deletion runs in a single coordinated pass across Cases, Contacts, Opportunities and custom objects, with Master-Detail relationships handled in the correct order so a child is not orphaned or a parent not deleted first. Large requests — 500,000 records and more — execute in governor-limit-safe batches, so a request does not fail against Salesforce's DML limits halfway through and leave the org in a half-erased state.

All of it runs as Apex inside your org. No customer data leaves Salesforce to be processed; there is no external service holding a copy of the request or the records.

Step 6 — Proof: the audit trail is the deliverable

Supervisory authorities expect a coherent story: what you found, what you did, and when. Privacy Rights Automation records that narrative natively in Salesforce for every request. The audit trail holds:

• Request metadata — type, regulation, deadline
• Discovery results — objects and record counts tied to the data subject
• Deletion or anonymisation outcomes per record, including blocked actions and the reason
• User or system identity, timestamps, and approval steps where configured
• The export packages generated for portability responses

Because the log lives in your org, compliance teams use Salesforce reporting and list views on it, and export it to PDF or CSV for a regulator without copying sensitive content into an external ticketing system. That last point is the whole reason to keep fulfilment native: the evidence stays where the data is.

Where this is running today

Two customers on our case-study pages run this end to end.

Floor & Decor needed CCPA DSAR fulfilment for customer data in Salesforce, driven from a OneTrust privacy portal. The implementation integrated REST and Invocable APIs through enterprise service-bus middleware; Cloud Compliance released specialised API versions to speed the deployment. Result, in the company's words on our site: automated CCPA DSR fulfilment through existing privacy infrastructure, with no custom-development technical debt. Read the case study.

ClearChoice Dental Implant Centers had patient information in Salesforce and no DSAR automation. They deployed Privacy Rights Automation for portability and deletion requests under CCPA and CPRA, with multi-format extraction — PDF, CSV, Excel, JSON — on a metadata-driven approach that survives an evolving data model. Result: hundreds of hours saved in manual DSAR processing and automated patient-rights fulfilment. Read the case study.

What automation does not do

It automates the process, not the outcome. It does not decide whether the person is who they say they are. It does not decide whether a retention obligation overrides an erasure request — it surfaces the conflict and blocks the deletion until a human rules. It does not make a regulator agree with you. What it does is remove the three failure modes that turn a routine request into a finding: incomplete discovery, unsafe deletion, and missing proof.

A checklist before you automate

1. Inventory the objects that hold personal data, including custom objects and Marketing Cloud. If you cannot list them, discovery has to be graph-based, not list-based.
2. Write down the deadline per regulation you are subject to and where the clock starts. Put it in the request template.
3. Define the blocking rules — contracts, holds, retention periods — before the first automated deletion, not after.
4. Decide delete versus anonymise per object. Retention and erasure are one policy, configured twice.
5. Choose the intake path: UI, REST, or your privacy suite by API. Do not run two intake forms.
6. Agree what the audit export must contain with whoever answers the regulator, and test that export before you need it.

The short version

A DSAR is six steps. Manual Salesforce handling breaks at discovery, cascade-safe deletion, and proof, and costs about $1,524 a request by Gartner's estimate. Automating it means one identifier in, every related record found, deletion blocked where the law says so, execution in safe batches, and an audit trail generated in your org — inside a clock that runs from one month (GDPR) to 90 days (DPDP). Two named customers run exactly this pattern today.

Sources

• Regulation (EU) 2016/679 (GDPR), Articles 12(3), 15, 17, 20
• California Civil Code §1798.130(a)(2) — CCPA response period
• 45 CFR 164.524(b)(2) — HIPAA right of access
• Personal Information Protection and Electronic Documents Act (Canada), s. 8(3)–(4)
• Digital Personal Data Protection Rules, 2025 (India), Rule 14
• Lei nº 13.709/2018 (LGPD), Article 19
• Gartner's $1,524-per-request estimate for manual DSAR handling, as relayed by Captain Compliance, DSAR Cost: How Much Does Each Cost? (captaincompliance.com/education/dsar-cost, accessed September 2026)
• Cloud Compliance case studies: Floor & Decor (retail) and ClearChoice Dental Implant Centers (healthcare)