The architecture was approved. The licensing math almost killed the engagement.
A multi-brand manufacturer we work with designed a clean structure: one HubSpot portal per business unit, each syncing to its own slice of Salesforce. There were good reasons. Strict data permissions between units. Distinct brands with their own domains. Different regional teams. On the whiteboard, it was the right answer. Then the cost model scaled across all the units, senior management saw the total next to a competing platform's number, and the entire multi-unit rollout froze while everyone went back to first principles.
I've now watched some version of this happen enough times to say it plainly: for multi-BU companies, portal architecture is a licensing decision before it's a technical one. Here's what actually decides it.
HubSpot keeps one contact record per email address. That sounds like trivia until one engineer buys from two of your divisions. Now one contact record has to represent two relationships, and if each division syncs to its own Salesforce lead, the contact syncs with the first lead the connector finds. The second division's data gets silently overwritten. If leadership wants clean P&L-level reporting out of that, it can't have it, and the right consulting move is to say so out loud rather than architect around a requirement the platform can't honor. On this project, leadership dropped the P&L segmentation requirement once they understood the trade.
A portal per business unit sounds contained until you count integration users. Each portal needs its own dedicated Salesforce API user, which means a paid license and a security review, per unit. Nine units, nine integration users, nine conversations with the security team. Budget for that on day one, not week ten.
If you go multi-portal, the cross-portal tooling has limits that only surface once you need them: cross-account reports cap out at a handful of accounts, multi-touch attribution needs the top licensing tier, and all accounts have to sit in the same hosting region. One more trap from the field: if a domain is already verified in a legacy portal, connecting it elsewhere can break email sending for a sibling business unit. Check domain verification before you promise anyone a go-live date.
None of this means Business Units always beats multiple portals. Genuinely separate businesses with no shared contacts and hard compliance walls are often better off separate. The rule is simpler: model the full three-year licensing cost of both architectures, including add-ons, integration users, and the tier your reporting requirements force you into, before anyone presents to the board. Architecture decks get approved. Invoices get escalated.
If you're mid-decision on this, we've built the comparison enough times to have opinions. Happy to share the framework.