Martech Workflow Automation for CCPA and CPRA

What to take away

Where CCPA and CPRA obligations land inside a martech workflow automation build

The California Consumer Privacy Act gives California residents rights over the personal information a business collects, and the California Privacy Rights Act amended and expanded it. It defines what a business must do when a consumer opts out or asks for deletion.

The California Privacy Protection Agency (CPPA) is the dedicated state agency charged with administering and enforcing the CCPA as amended by the CPRA. The California Attorney General also retains enforcement authority, so check current agency guidance and enforcement actions as you translate requirements into workflow controls.

At collection, give consumers a notice identifying the categories of personal information collected, the purposes for collecting or using it, whether it is sold or shared, the retention period or criteria, and a link to the privacy policy. Include the categories of sensitive personal information collected, and update the notice before introducing a new purpose.

That is a build problem, not a legal memo. The legal team decides what the policy says. Marketing ops decides whether the workflow can actually honor it at 2 a.m. on a triggered send.

Start by inventorying the automations that touch personal data. Most teams find three clusters: acquisition forms and landing pages, lifecycle and re-engagement campaigns, and transactional or service messages. Each cluster has a different consent standard and a different retention clock.

Write the inventory as a table before you touch a platform. The table becomes the specification you hand to whoever configures HubSpot, Salesforce Marketing Cloud or Braze, and it becomes the evidence file later.

The order matters. Consent capture has to exist before suppression logic can reference it, and suppression has to exist before a deletion request can be honored cleanly. Teams that build deletion first end up deleting records they never should have collected.

One more scoping decision: which states are in scope. California drives the CCPA and CPRA work, but Colorado, Virginia and Connecticut have their own statutes. New York, Texas and Illinois add sector rules or breach obligations of their own, so parameterize the California path by state rather than forking a separate workflow for each one.

Before configuration, define the person identifier used to join records, where consent status and its timestamp and source live, and which system is authoritative. If those decisions are still open, the design questions in this piece on identity, consent and triggers are worth settling before configuration starts.

Consent capture: CCPA and CPRA sections in HubSpot, Salesforce Marketing Cloud and Braze

Consent capture is the cheapest part of the build and the part that most often gets skipped. A checkbox that writes a boolean is not consent capture. You need the status, the text the person agreed to, the version of that text, the timestamp, and the source.

HubSpot

HubSpot stores consent in the contact property model and in subscription types. Create a custom property group for privacy fields so they do not get mixed into lead scoring. Set subscription types to reflect your actual communication categories rather than one generic newsletter toggle, because a single toggle cannot express a limited purpose.

On forms, use the legal consent checkbox option rather than a plain checkbox. It stores the consent text and the timestamp with the submission, which is exactly the evidence you need. Turn on the setting that requires the checkbox before submission.

For the do-not-sell-or-share signal, add a custom boolean property and include it as a suppression criterion in every active list. HubSpot will not infer it for you.

Salesforce Marketing Cloud

Marketing Cloud splits consent across subscriber attributes, publication lists and consent records in the consent data model. Use the consent data model rather than a custom attribute if you want the platform to block sends automatically. Custom attributes only work if every query and every send definition remembers to check them, and eventually one will not.

Entry points should be gated on the consent record, not on the email address alone. Where a form feeds Marketing Cloud through a CloudPage or an API call, write the consent record in the same transaction as the subscriber record. Split writes are how you get subscribers with no consent history.

Braze

Braze handles subscription groups for channel-level opt-in and custom attributes for everything else. Create a subscription group per communication category, and use the global subscription state only for a full stop. Braze will enforce subscription group state at send time, which is the behavior you want.

For consent text and version, use a custom attribute pair and make them required in the form or API payload. If your intake API accepts a subscriber without a consent version, the build is incomplete.

The shared rule

Whatever the platform, the consent record must be written before or with the profile, never after. A queue that writes consent asynchronously is a queue that will eventually drop a message.

The NIST Privacy Framework is a useful structure here. It separates identify, govern, control and protect functions, and that maps onto consent capture, purpose setting and suppression. Teams that use it tend to produce a control list that survives staff turnover.

Suppression and opt-out logic that survives list imports and re-engagement campaigns

Suppression breaks in three predictable places: bulk imports, list uploads from events, and re-engagement campaigns that were built before the opt-out existed.

A suppression list is only as good as its refresh schedule. If the list is refreshed manually, it is stale. Build a scheduled job that pulls opt-outs from every intake source, deduplicates, and writes to the suppression list in each platform on a fixed cadence. Daily is normal. Hourly is better for high-volume senders.

If the business sells or shares personal information, provide the required conspicuous “Do Not Sell or Share My Personal Information” link and honor Global Privacy Control (GPC) as an opt-out preference signal. Route both channels to the same suppression state, do not require identity verification for an opt-out, and process opt-out requests within 15 business days.

Imports

Every import needs a pre-flight check. Run the incoming file against the suppression list and quarantine matches before the import writes to the database. If your process imports first and suppresses later, you have a window in which a person who opted out receives mail.

Re-engagement campaigns

Re-engagement is where old consent gets reused without anyone noticing. A win-back campaign built two years ago may reference a list that no longer reflects opt-outs. Audit every re-engagement path against the current suppression source before the next send.

Set re-engagement to require a positive consent signal, not the absence of an opt-out. Absence of an opt-out is not consent, and under the CPRA's purpose limitation principle, a person who agreed to a newsletter did not agree to a win-back campaign about a different product line.

Cross-platform drift

HubSpot, Salesforce Marketing Cloud and Braze will not stay in sync on their own. Pick one system as the consent source of truth, usually the CRM or the CDP, and treat the other two as downstream consumers. Push changes out; do not let each platform collect its own opt-outs.

When choosing an integration path, verify that syncs cannot overwrite a newer opt-out or consent state. The HubSpot Ops Hub vs. Zapier comparison can inform that tool choice, but the control must be tested in your own data flow.

Data-subject requests: access, deletion and correction steps as automation branches

A data-subject request is a workflow with a clock on it. For a request to know, delete, or correct, verify identity using reasonable methods appropriate to the request and the sensitivity of the information, without collecting more data than necessary. Confirm receipt within 10 business days and respond within 45 calendar days; when reasonably necessary, extend once by up to 45 additional calendar days and notify the consumer within the initial 45-day period. The California Attorney General's privacy and data security enforcement page publishes enforcement actions and guidance relevant to these controls.

Build the workflow so the clock is visible and the steps are owned.

Access

Access requests are mostly a search problem. Maintain a system inventory that lists where personal data lives and who owns each system. Without it, every request becomes a manual archaeology project and the response window gets tight.

Build a saved query per system that returns the fields you would disclose. Test it quarterly, because schemas change and a saved query that returns nothing looks like a clean result.

Deletion

Deletion is harder than it sounds. You cannot delete what you are legally required to retain, and you cannot leave the record in a downstream platform that will re-import it. Sequence deletion so the source of truth is cleared first, then downstream systems, then any derived segments or audiences.

Suppression entries are a special case. Many teams keep a minimal suppression record after deletion to honor the opt-out. That is a legitimate practice, but it must be a deliberate decision recorded in the workflow, not an accident of how the platform stores data.

Correction

Correction requests are the least common and the most damaging when handled badly, because a correction that does not propagate leaves two conflicting records. Route corrections through the source of truth and push the update to HubSpot, Salesforce Marketing Cloud and Braze in the same run.

Before selecting tooling, confirm that it can preserve data lineage, route a request across connected systems, and execute retention and deletion rules. A platform comparison alone cannot establish that your configuration does so; the comparison in this review of low-code marketing workflow automation platforms can support the evaluation.

Sensitive data limits and the CPRA purpose-limitation settings teams forget

The CPRA created a category of sensitive personal information with additional limits on use. In a marketing context, that usually means precise geolocation, some health-related inferences, racial or ethnic origin, religious beliefs, and information about sexual orientation.

Most marketing automation platforms will happily store any of that in a custom property. The limit has to come from your build.

Purpose limitation in practice

Purpose limitation means the data collected for one stated purpose is not reused for another. In platform terms, that is a set of controls most teams never configure:

Sensitive attribute handling

Restrict sensitive attributes to a small number of roles. In HubSpot, that means property-level permissions. In Salesforce Marketing Cloud, it means limiting access to the data extensions that hold those fields. In Braze, it means restricting custom attribute visibility and excluding those attributes from segmentation.

Also check what your ad platforms receive. A hashed audience built from a segment that includes sensitive inferences is still a use of sensitive data. The FTC's privacy and security guidance hub is a reasonable starting point for how the agency frames unfair or deceptive data practices.

Read it before you ship an audience that depends on inferred attributes.

Retention

Set retention per data category and automate the deletion. A retention rule that lives in a policy document and not in a scheduled workflow does not exist. Build the job, monitor the job, and log the job.

For each data category, define a retention trigger, the systems holding copies, and the job that deletes or de-identifies them; include proof of completion in the log. For a broader treatment of how retention and lineage get tested in practice, this piece on marketing data governance covers the operational side.

Vendor and processor terms: what to demand from each platform before go-live

Contracts are part of the build because they determine what you can prove. Before go-live, get written answers to the same set of questions from each platform.

Ask each platform vendor:

Push for the service provider designation where it applies. A vendor acting as a service provider has narrower rights to use the data than one acting as a third party, and that distinction changes your obligations.

Ask specifically about suppression propagation. If the platform shares audiences with ad networks, you need to know whether an opt-out reaches those networks and how quickly.

Get the answers in writing and store them with the workflow documentation. When a regulator or an auditor asks how the automation enforced the rule, the contract is part of the answer.

Testing and evidence: audit trails that show the workflow enforced the rule

An audit trail is not a log file. It is a set of records that lets someone reconstruct what happened to a specific person's data and why.

What to test before go-live

Run these as scripted tests with a synthetic profile in each platform:

What to keep as evidence

The evidence set is small and specific. Consent text versions with effective dates. Timestamps of consent and withdrawal. Suppression list snapshots with the date taken. Request tickets with received and completed dates. Send logs showing suppression applied. Import logs with match counts. Configuration screenshots at the time of go-live.

Store evidence where it survives staff changes. A shared drive owned by one person is not a record.

Review cadence

Test the whole chain quarterly. Re-test after any platform release that touches forms, consent records or suppression behavior. Re-test after any import process change, because imports are where suppression breaks.

Keep a single page that lists each control, the platform, the owner and the last test date. That page is what you hand over when someone asks whether the automation actually enforces the CCPA and CPRA rules you wrote into policy.

For each workflow, record its trigger, any manual steps, the system owner, the deadline, and the evidence that proves completion. This marketing operations workflow audit template covers the decisions that come up most often.

Common questions