A HubSpot preference centre built for a single business is a reasonably well-understood piece of work. Building one to serve every business unit inside a group that grew by acquisition is a different problem, and the hard part is never the interface a contact sees. It sits in the data underneath it, specifically the work of reconciling years of consent records that evolved independently before that data can be trusted. This guide walks through a real, shipped example of that build for a multi-business-unit insurance group, and the trade-off that shaped almost every decision inside it.
The Problem: Consent Scattered Across Business Units
A group that grows by acquiring other companies inherits their consent history along with everything else. Each business unit arrives with its own record of who opted in and out of what, its own way of labelling a subscription, and no shared reference point with any other unit in the group. Nobody designed it this way on purpose; it is simply what several previously independent consent systems look like once they end up under one roof. Unreconciled, the group cannot say with confidence what any particular contact has consented to hear from it, and the ICO’s guidance on what counts as valid consent sets a specific bar for what a defensible answer needs to look like, which a group answer built on guesswork will not clear.
We ran into a harder version of this problem than a simple “different systems, same idea” scenario. The subscription identifiers themselves were the trap: two business units could each have an ID that looked interchangeable on the surface while meaning something entirely different underneath, one representing a broad marketing opt-in and the other something narrower and more specific. Assuming the two were equivalent because they looked alike would have been wrong in a way that stayed invisible right up until a contact complained that a preference they thought they had set had quietly not applied.
The HubSpot Preference Centre Is Mostly a Mapping Problem
One HubSpot preference centre now serves every business unit through the same single mechanism, so nobody has to keep several separate flows in step by hand afterwards. HubSpot’s own subscription types documentation covers the native building blocks this sits on top of, subscription types and a preference centre page, but the native tooling only becomes trustworthy once the group-wide architecture underneath it has been designed. One capture point means the same preference is written to the same place no matter which unit a contact first dealt with, and one shared record means it stays put rather than quietly drifting between separate databases over time.
The preference centre itself could not go live until the underlying opt-out mess was untangled first. That meant going unit by unit through every subscription-type identifier the group had, working out what each identifier stood for in practice, because in a group assembled from separate acquisitions a familiar-looking naming pattern rarely signals a shared meaning. Two units with a genuinely equivalent consent type got folded into one shared category. Two units whose types did not actually match stayed separate, rather than being squashed together for the sake of a neater-looking list of options.
A preference centre’s front end is the easy half of this kind of build. Reverse-engineering the true meaning behind a decade or more of separately maintained subscription IDs, without treating any single business unit’s own records as the reference point everyone else gets checked against, is a different job entirely. That work consumed most of the engagement time. We went back to source: subscription names, whatever historical opt-in wording survived, and the original consent-capture forms where they still existed, until each ID’s real meaning was clear enough to trust. Anywhere the historical trail ran out, we treated the gap as a reason to hold back rather than a reason to guess, and defaulted to whichever reading of a contact’s consent was more restrictive.
Fidelity Over Consolidation
Every decision in this build came down to the same trade-off: how far the preference model could be simplified before that simplification started erasing a distinction between two units’ consent records that actually mattered under GDPR. We chose fidelity every time the two pulled in different directions, and that trade-off was not a close call at all. Get it wrong by over-consolidating and the failure mode is a compliance problem; get it wrong by keeping too much granularity and the failure mode is, at worst, a slightly cluttered admin screen. Those two outcomes do not carry the same weight, and that asymmetry is what actually settled the trade-off each time it came up.
Getting the consent wrong under a tidy-looking model is a worse outcome than a messier model that gets it right, because this build was judged on accuracy, not on how clean the option list looked. The temptation to over-consolidate usually comes from a reasonable place: fewer categories are genuinely easier for a contact to understand and for an admin to maintain, and a team under deadline pressure will always find the simpler model easier to ship. Resisting that pull specifically where the underlying records disagreed, rather than everywhere, is what kept the result both usable and accurate instead of trading one for the other across the board. What it produces is an architecture that respects each unit’s own consent boundary: no genuinely separate category from one unit gets folded away or hidden inside another unit’s view of the same contact, and no consent given to one unit gets treated as if it automatically extended to a different, unrelated one.
Built for a Group That Keeps Acquiring
A group built by acquisition is not finished acquiring the moment a preference centre ships, so a data model built only for today’s business units would need rebuilding the next time another one joins. New units get onboarded into the subscription-type mapping as an ongoing structure rather than a one-off migration that closes once it ships, precisely so the group’s own team could extend it later without pulling the original build team back in every time the group’s shape changed again.
That onboarding path has a defined shape: any subscription type a newly acquired unit brings gets checked against the group’s shared categories, and only a clean match goes through automatically; anything else is routed to manual review rather than auto-mapped and reintroducing the exact over-consolidation risk the original build was designed to avoid. The group’s own team got that process in writing rather than inheriting it as tribal knowledge, because an architecture only its original builder can extend safely has not actually solved the group’s problem; it has just handed the same problem to whoever runs the next acquisition. On a technical level, this kind of onboarding structure is far easier to justify when the platform itself supports setting subscription state without a person editing records by hand; HubSpot’s own Communication Preferences API is the general capability that makes that possible, whatever the specific mapping decision for a given unit ends up being.
The Outcome
The group now has one place where a contact’s preferences live, whichever business unit they first engaged with. A choice made once does not need re-establishing somewhere else in the group, and it does not get quietly overridden by an old record sitting in a system nobody is watching any more. We are not attaching a single locked metric to this build, and saying so plainly is itself worth more than reaching for a number that would overstate what changed. For a group assembled from separate acquisitions, going from several answers to the question of what a contact agreed to, down to one, is the actual result, and it is a result a regulator or a contact can be given confidently rather than pieced together after the fact from whichever system happens to still hold the record.
Related Reading
For the CRM foundation this kind of build sits on top of, see HubSpot Consultancy. For the strategy layer above the platform itself, see RevOps Consultancy. On the automation side of consent specifically, Automating Consent Management With n8n, HubSpot and DocuSign covers the workflow layer that can sit on top of a preference architecture like this one, and Automating GDPR Consent Sync in CRM With n8n covers keeping consent state in sync once it exists in more than one place.
Go deeper: RevOps Automation Maturity Model · HubSpot Lead Routing Automation · n8n vs Zapier for RevOps Automation
Frequently Asked Questions
Wouldn’t a separate preference centre per business unit be simpler to build?
Simpler to launch, harder to trust afterwards. Two flows that started in step drift apart the moment one unit’s contact updates a preference and the other unit’s copy of that record does not hear about it, and a stale record in a system nobody is actively watching can quietly override a choice a contact only just made. A single capture point feeding one shared record removes that entire failure mode rather than managing around it.
What was the genuinely hard part of a build like this?
Not the interface, and not the CRM configuration. Different business units had subscription identifiers that looked alike on the surface but carried different meanings underneath, so a naive one-to-one mapping between units would have quietly misrepresented what specific contacts had actually agreed to. Working out which identifiers were genuinely equivalent, and which only looked that way, took most of the engagement time.
Should this run as its own dedicated consent-management platform instead?
Not in this case. A standalone platform brings its own vendor contract and its own procurement process, and it becomes one more place for commercial and compliance staff to check on top of the CRM that already has the answer. Building the preference logic inside the CRM the group already runs on removes that reconciliation problem rather than adding to it.
What happens when the group acquires another business unit?
Its existing subscription types get checked against the categories already in use across the group, and anything that does not line up cleanly goes to a person to decide rather than being folded in automatically. That single rule is what stops the fidelity-over-consolidation trade-off from quietly eroding every time the group grows.