Rebuilding GDPR Consent as Country-Tiered Workflows
A country-blind consent gate would have gone live undetected if an adversarial QA pass hadn't caught it. The first build marked any contact marketable on double opt-in alone, with no check on country. We rebuilt roughly fourteen legacy campaigns as five HubSpot workflows and five country-cohort lists, keyed on a Legal-approved CSV, then closed that gap with a cohort re-check before the corrected version went into the sandbox.
Executive Summary
Context
A global enterprise SaaS company anchoring its marketing operations to a new HubSpot instance sold into North America, EMEA and APAC under GDPR. Any consent rebuild had to preserve the country-level distinction its Legal team had already approved, not collapse it into one global opt-in flag.
What We Built
We built five HubSpot workflows and five country-cohort lists driven by a Legal-approved CSV, replacing a single global opt-in flag with a country-aware consent state machine. It gates marketable status, times a region-specific confirmation send, and wipes the consent record on unsubscribe.
Tech Stack
- HubSpot
- Salesforce
Not a fit if your consent obligations are uniform across every market you sell into, since the country-cohort design exists to enforce different rules per region. It also assumes your Legal team can produce and maintain a country-tier mapping, and that an adversarial QA pass happens before go-live rather than after.
The Challenge
The legacy platform enforced GDPR consent through roughly fourteen separate country-specific campaigns. Each carried its own opt-in, double opt-in and unsubscribe logic, approved by Legal and added to over many years.
Collapsing that into a single HubSpot opt-in flag would have erased the country distinction Legal required. HubSpot doesn't have a native concept of a country-tiered consent state, so the rebuild had to carry the per-country logic itself.
Our Approach
Five workflows replace the fourteen legacy campaigns, each keyed on country-cohort list membership instead of logic written into the workflow itself. WF-1 runs on a country or customer-status change. WF-2 fires when opt_in becomes true. WF-3 fires when double_opt_in becomes true. WF-4 fires when unsubscribed becomes true and wipes the consent record. WF-5 fires when a custom double-opt-in flag becomes true. A Legal-supplied CSV compiles into cohorts.json, so re-tiering a country is a data change, not a workflow rewrite.
An adversarial QA pass against the first build found that WF-3 granted marketable status the moment double opt-in completed, with no check against the contact's own country cohort. That was a real compliance defect, because it could market to a country under a stricter consent tier than its record supported. We fixed it by adding a cohort-list re-check to WF-3, plus a 15-minute wait ahead of the DACH welcome send so that cohort clears the same gate as every other market.
WF-5's bypass flag now auto-clears after seven days. The corrected build sits in the sandbox disabled and unenrolled, blocked only on delivery of the client's EN/DE confirmation and DACH welcome templates.
Impact
Country tier changes without a workflow rewrite
Cohort membership comes from a Legal-supplied CSV rather than hardcoded logic, so adding a country or correcting a misclassification is a data change to cohorts.json, not a rebuild of any of the five workflows.
A country-blind marketable status gap closed before go-live
WF-3 now re-checks a contact's country cohort before granting marketable status. The defect the QA pass caught, where double opt-in alone made any contact marketable, can't recur once the workflow re-enables.
Unsubscribe fully wipes the consent record
WF-4 clears the consent record the moment a contact unsubscribes, rather than leaving a stale opt-in flag set alongside the unsubscribe status, which would otherwise read as contradictory consent state on audit.
A third-party bypass that cannot silently persist
WF-5's third-party bypass flag auto-clears after seven days, so a third-party-sourced exception to the standard consent flow carries a built-in expiry rather than depending on someone remembering to revoke it.
Five workflows replace the legacy campaign set: WF-1 triggers on a country or customer-status change, WF-2 on opt_in becoming true, WF-3 on double_opt_in becoming true, WF-4 on unsubscribed becoming true, and WF-5 on a custom double-opt-in flag becoming true. Each keys on country-cohort list membership rather than logic written into the workflow itself.
Country tiers come from a CSV the client's Legal team approves and supplies, compiled into cohorts.json and read by five country-cohort lists. Re-tiering a country is a data update, not a change to any workflow's logic.
As first built, WF-3 granted marketable status on double_opt_in alone. An adversarial QA pass caught that a contact completing double opt-in became marketable regardless of country, and the fix added a cohort-list re-check to WF-3 before marketable status is granted.
WF-3 waits 15 minutes before sending the DACH welcome email, so the German and Austrian cohort clears the same consent gate as every other market rather than receiving it ahead of confirmation. WF-5's third-party bypass flag auto-clears after seven days rather than persisting indefinitely.
The first build marked any contact marketable on double opt-in alone, with no check on country. HubSpot has no native country-tiered consent state. Now a Legal-approved CSV compiles into cohorts.json, and five workflows key on country-cohort list membership, so re-tiering a country is a data change, not a workflow rewrite. WF-3 now grants marketable status only if the contact's country cohort passes its re-check.
FAQ
A contact who completes double opt-in gets marked marketable without regard to which country's consent rules apply, a real compliance defect rather than a theoretical one. Catching it requires an adversarial QA pass that tests the workflow against every cohort, not just the default path; here that pass added a cohort-list re-check to the workflow before it grants marketable status.
A CSV compiled into a lookup file lets Legal own the country-tier mapping directly, and lets a re-tier or correction ship as a data change rather than a workflow edit. Here five country-cohort lists read the same compiled file, so all five workflows stay consistent without duplicating the logic five times over.
