HubSpot Brands (Business Units) vs. Multiple Portals: How to Structure CRM for Multi-Brand Organisations

Getting your HubSpot architecture wrong at the start is expensive to fix later. Whether you are migrating to HubSpot for the first time or sitting on multiple portals wondering if consolidation makes sense, the same question comes up: Do we run one unified portal using Brands and use teams for structure, or do we keep separate portals?

The answer depends on how your brands operate, how your data needs to be governed, and where the line sits between operational efficiency and regulatory constraint. Both approaches work, but the trade-offs of each are not obvious from the documentation alone, and most organisations only surface them mid-implementation or after go-live.

What Are HubSpot Brands (Business Units)?

HubSpot's own positioning is clear: Brands are designed for organisations with multiple brands, one business model, one CRM, and one marketing organisation. They are not designed for strict data segregation.

HubSpot Brands (formerly Business Units) is an add-on for Marketing Hub Enterprise and operates as its own environment within the portal with its own branding, marketing assets, user permissions, and reporting, while sharing a centralised CRM database underneath.

This addresses the core tension of multi-brand management: the need for both separation (for brand identity and operations) and centralisation (for data, reporting, and efficiency).

With Brands, you can:

• Customise branding per entity. Each Brand gets its own brand kit: logos, colours, and email footers.
• Separate marketing assets. Landing pages, emails, forms, and blogs are assigned to a specific Brand.
• Segment contacts by Brand. Audience partitioning ensures Brand A's contacts do not receive Brand B's marketing.
• Control user access. Teams can be restricted to view and edit only their Brand's assets.
• Report by Brand. Dashboards can show performance for a single Brand or compare across all Brands.

A simple way to think about it: Brands handle the marketing-side separation (email preferences, campaign assets, landing pages, forms), while Teams and Permissions handle the sales-side separation (who can see which contacts, deals, pipelines, and records). Most multi-brand setups need both to work together.

But Brands are a marketing-layer separation, not a data-layer separation. Underneath, all contacts, deals, companies, and workflows live in the same database. Visibility is controlled through teams and permissions, not through hard partitions.

What Is a Multi-Portal Setup?

A multi-portal setup gives each entity its own HubSpot instance. Separate contacts, separate deals, separate workflows, separate contracts. This is common in organisations that have grown through acquisition or expanded regionally without a centralised CRM strategy.

HubSpot's Multi-Account Management can connect these portals, enabling data mirroring between accounts, asset copying (forms, emails, lists), and centralised oversight. But day-to-day, each portal is an independent environment. Cross-account reporting is not native; group-level dashboards require an external BI tool or data warehouse.

Benefits of a Unified Portal with Brands

Running multiple portals on different subscription tiers and billing cycles creates compounding operational drag. A unified portal addresses this across five areas.

Unified reporting

Data lives in one place. One reliable view of performance across brands replaces quarterly spreadsheet reconciliation. Group-level dashboards are native rather than stitched together from manual exports.

Centralised governance

A common hesitation when considering a unified portal is whether teams can be properly restricted from seeing each other's data. In practice, HubSpot's teams and permissions can handle the majority of partitioning requirements without needing separate portals. Some examples:

• CRM record access can be restricted so users only see contacts, companies, and deals owned by their team.
• Properties can be locked at the field level, making them invisible to users outside that team.
• Pipelines can be restricted to assigned teams. Marketing assets, workflows, lists, and dashboards can all be team-assigned.
• Custom CRM views mean a salesperson in Singapore sees only their relevant records, products, and deals.

Standardised processes

In separate portals, teams use HubSpot differently, leading to uneven processes and data quality. In a single portal, a workflow that works in one market can be cloned for another rather than rebuilt from scratch.

Simplified contracts

One agreement, one billing cycle, one renewal. The admin reduction alone justifies this for many finance teams.

Efficient scaling

Adding users, tools, or new markets to an existing portal is straightforward. In a multi-portal environment, each new market often means a new instance and a new contract.

The Trade-Offs of a Single Portal

As HubSpot's own documentation makes clear, a single portal cannot support hard data silos. Permissions help with visibility, but core data and system settings are shared.

In practice, this surfaces across four areas.

1. Contacts Are Shared Across All Brands

One email address equals one contact record. This is the foundation of cross-sell visibility and the constraint that catches most organisations off guard.

Where this gets nuanced: marketing contact status is a portal-level property. You cannot set a contact as a marketing contact for one Brand and a non-marketing contact for another. The same applies to lifecycle stages, which are shared across the portal by default. You can create Brand-specific custom lifecycle properties, but certain HubSpot tools (Ads, Events) still sync back to the default.

2. Core System Settings Are Global

A single portal has one time zone setting. Reporting filters, workflow triggers, and segmentation logic all reference this. Individual users see activities in their local time zone, and email sends can be scheduled to the recipient's time zone. But month-end close reports are anchored to the portal time zone. For a group operating across Singapore, London, and Sydney, this creates a reporting offset of up to 16 hours.

3. Some Core Properties Are Always Shared

Certain default properties cannot be replaced or overridden per Brand. You can create Brand-specific custom properties and restrict access by team. But a workflow referencing a shared property as an enrolment trigger can affect contacts across every Brand.

The fix is governance. Brand-specific custom properties as triggers and clear naming conventions.

4. Some Integrations Only Support One Account Connection

Some integrations link to the entire portal rather than a specific Brand. Salesforce supports one native connection per portal. Brands using the same third-party apps with different accounts need to consolidate into a single instance before integrating. Social media is the exception; accounts can be added per Brand.

When a Single Portal with Brands Is the Right Fit

Brands work when the organisation has shared client bases, similar deal structures, and a centralised marketing operation.

The typical profile: a group where the incorporation arm, the HR arm, and the advisory arm all serve the same companies in the same markets. Cross-sell is a strategic priority. Leadership wants a single dashboard. Marketing wants brand-specific campaigns from one platform.

The critical requirement: no entity needs hard data segregation from another. If permissions-based visibility control is sufficient, Brands work.

When to Use Multiple HubSpot Portals Instead

There are scenarios where a unified portal through Brands is not viable, regardless of the operational benefits.

Legal restrictions that prohibit sharing data from the same CRM. If NDAs, regulatory obligations, or client confidentiality clauses require hard data separation between entities, permissions-based visibility controls are not sufficient. Those entities stay in separate portals.

Separate billing requirements. If brands or entities need to receive independent invoices and manage their own HubSpot contracts, multiple portals are the only option.

Data residency requirements. If entities need to host their data in different global regions, each requires its own portal. HubSpot data hosting is set at the account level.

Fundamentally different business models. One entity runs high-volume transactional sales, and another runs long-cycle advisory, creating friction when forced into the same pipelines and workflows.

In these cases, Multi-Account Management keeps portals connected through data mirroring and shared assets, while maintaining operational independence.

Your Decision Checklist: Brands vs. Multiple Portals

Not sure which option is best suited to manage and organise your brands?

HubSpot recommends considering these questions when choosing between Business Units and Multiple Accounts/Portals.