Multi-Country HubSpot Rollout: One Portal, Local Processes

A shared CRM needs common definitions. Local teams still need a system that reflects how they sell and serve customers. The design problem is deciding which differences belong in configuration, which belong in data and which reveal a process that has not been agreed.

This guide describes a general approach to multi-country CRM design. The examples are illustrative and do not describe any client’s configuration.

Most multi-country problems turn out to be ownership questions nobody settled, which the configuration then hardcodes. A second pipeline, a duplicated field or an extra account often records a decision that was never made, not a real difference between markets.

If you run HubSpot in a single country, most of this still applies: several teams, brands or business lines in one account raise the same questions. Only the section on running several accounts is specific to multi-country setups.

If you only have two countries, my advice is the same, just earlier: decide which pipelines and properties each country and each sub-team needs, write a short governance rule on day one, share the costs and features of the portal openly, and agree a naming convention before anyone creates a field.

Start with a shared operational vocabulary

Agree what a customer, opportunity, qualified lead and closed deal mean across the organization. If markets use incompatible definitions, a consolidated dashboard will produce a number without a common interpretation.

Next, separate four ideas that a single “country” field tends to blur. In HubSpot, a property is a field on a record, and each of these deserves its own property with a written definition, because they can differ on the same account:

• Legal entity: the group company that signs and invoices; finance reporting depends on it.
• Selling market: the team that owns the commercial relationship; routing and targets use it.
• Service location: where the work is delivered, possibly several places; service coverage depends on it.
• Communication language: the language a contact should be written to in; templates and consent wording use it.

One portal or several?

A portal is one HubSpot account, with its own records, users, settings and billing. My default is one portal when markets share customers, reporting and administrators. A customer buying in three markets then exists once, and group reports need no cross-account reconciliation.

HubSpot’s official alternative is multi-account management. A main account on an Enterprise subscription can connect up to 29 other accounts, each on Professional or Enterprise. It can mirror contact and company activity between accounts as read-only data, copy assets such as forms, lists and automated emails, and build reports across accounts. Those cross-account reports only work when all the accounts host their data in the same location.

Several portals are justified when the constraint is real: a legal or data-hosting requirement one account cannot meet, or businesses that genuinely do not share customers, teams or reporting. “The Spanish team wants its own settings” is usually a permissions question, not a reason for another portal.

Agree who pays before you agree on fields

On large shared portals, the hardest conversations are usually about shared properties, shared records and, above all, money, rather than pipelines. One portal means one bill: marketing contacts, paid seats and the subscription itself are paid at account level, and then someone has to split them. A market with a handful of users will reasonably ask why its share rises when another market imports a large database.

Preventing the increase worked better than arguing about who pays. Agree early how costs are allocated (by seats, by marketing contacts, or a fixed share per market), and give each market the tools to keep its own costs down: which contacts are set as marketing contacts, who gets a paid seat and who only needs to view. Settle this before the first market goes live.

Brands and business units

For groups with several brands, HubSpot’s feature is called Brands: an add-on for Marketing Hub Enterprise, where each add-on provides one brand. Creating a brand adds a contact property that records which brands a contact belongs to. HubSpot’s own documentation calls that property Brands in one place and Business Units in another, so check the label in your account.

Two behaviours matter for design. Email opt-outs are scoped per brand: a contact who unsubscribes from everything while you are working in one brand is only opted out of that brand’s subscriptions. And a marketing email’s brand cannot be changed once the email is created; you clone it into the right brand instead.

So brands solve marketing consent and sender identity: who an email comes from and what the recipient agreed to. The brand property can filter lists, workflows and reports, but brands do not control who sees which records, pipelines or deals. Teams and permissions do that.

When Breeze agents first appeared, on a shared portal there was no way to limit who used them by team, and no agreed rule yet on which markets or product lines an agent should serve. With many markets in one portal, the safe choice was to wait until the rules existed. HubSpot’s options here change quickly, so check what the current release lets you restrict before you promise a market its own agent.

Currencies

Each HubSpot account has one company currency. It is the default for new deals and the basis for the deal amount converted into company currency, which HubSpot’s deal totals and revenue reports use. Other currencies can be added, each with an exchange rate.

The currency documentation describes a behaviour worth explaining to finance early. Open deals use the most recent exchange rate automatically. Closed deals keep the rate in effect when they closed, and later rate changes do not update them. A pipeline report and a closed-revenue report can therefore apply different rates to the same currency, by design.

Adding currencies or editing rates in settings requires Super Admin access or billing permissions, and the rate stored on an individual deal can also be overwritten by Super Admins, workflows, integrations or the API. Name a rate owner, agree how often rates are updated and record the source. Otherwise rates get edited by whoever has access, whenever someone notices a gap.

Permissions per market

Three HubSpot features do most of the work. A team groups users: “team only” permissions limit people to records owned by their team, and on Enterprise, a parent team sees records owned by the teams nested below it. A permission set is a saved role template (Enterprise, up to 100 per account); assigning one overrides that user’s individual permissions. Finally, access to assets such as pipelines, workflows, properties, reports, dashboards and forms can be limited to specific teams, with subscription requirements that vary by asset.

I aim for one role template multiplied by the number of markets, not hand-built users. Three permission sets (sales rep, sales manager, marketing user) and one team per market mean a new rep in a new market is one team and one set to assign. The full approach, including seats and offboarding, is in designing HubSpot access by role, not by person.

Decide where each variation belongs

A pipeline is the sequence of stages a deal, ticket or other record moves through. HubSpot’s pipeline documentation itself suggests using one pipeline with team-only permissions rather than a pipeline per team. Custom pipelines also count against one limit shared across all objects, and restricting a pipeline by team requires a Professional or Enterprise subscription.

Property governance and naming

Every property has a label people see and an internal name that imports, connected tools and developers’ code rely on. According to HubSpot’s property documentation, the internal name cannot be edited after creation. A property created as segment_es during the pilot keeps that name for every market that follows.

Agree a naming convention, and who owns each property group (HubSpot’s folders for related properties), before the first market goes live. When one market needs a different option, add a value to the shared dropdown. “Customer segment” with a value only Germany uses still reports in one column; a separate “Customer segment (DE)” creates a second column someone will have to merge later.

A problem I have seen more than once comes after go-live. Teams replace old properties with new shared ones while workflows still read and write the old fields. Every dependency then has to be found, switched to the new property and checked before the old one can be retired, and that clean-up takes far more effort than creating the new properties. Before you deprecate anything, list where each property is used: workflows, reports, lists, forms and integrations.

If I started a multi-country rollout today, the rule I would write on day one is about sharing existing data. HubSpot keeps changing, and every new team that joins wants to work with contacts already in the portal. That is the point of one portal. But the new team should write to its own properties, not overwrite values another team relies on. Without that rule, each new team and each product change edits someone else’s data without anyone noticing, and the portal eventually breaks in ways nobody can trace.

Where the data is hosted

Each HubSpot account is hosted in one location: the United States (two regions), Canada, Australia or the EU (Germany). You can check yours in settings under Privacy & Consent, then Data Hosting. HubSpot’s data hosting FAQ also notes that some data, including analytics and usage data, is transferred to the United States. If a market has hosting requirements, involve your legal and privacy advisers before choosing a portal structure. For the consent side, see the preference centre guide.

Rollout sequencing, market by market

1. Wave 0, the shared model. Build definitions, properties, pipeline stages, permission sets and naming in a sandbox, a test copy of the account, before any market goes live.
2. Pilot, one market with meaningful variation. The easiest market may not reveal the problems that matter. Choose one that exercises a second language, currency, brand or integration, and include incomplete records and cross-team handoffs.
3. Waves of three to five markets. Group markets with similar processes. Freeze the shared configuration during each wave; change requests queue for the window between waves. Plan each wave’s imports with the same migration checks.

Keep an exceptions log so local requests have a visible path. Record the need, affected users, reason the common model is insufficient and proposed owner. Decide whether the request belongs in the shared model, a local configuration or a temporary exception.

Temporary exceptions need a review date. Otherwise they become permanent differences that future administrators cannot explain.

Use an acceptance checklist before extending the rollout

• A test user for each permission set completes the agreed sales and service tasks.
• Team visibility behaves as designed: a rep sees their own market’s deals, not another market’s, and a regional manager sees the teams nested below.
• A closed deal in a second currency shows the same company-currency amount on the record, in the pipeline report and in finance’s figure.
• A test contact who unsubscribes from everything in one brand keeps the expected email subscription types in the other brand.
• An imported account active in two markets keeps its identifiers, its links to related contacts and deals (HubSpot calls these associations) and the four location and language properties, including after integration updates.
• Routing has a receiving owner and a fallback for uncertain records.
• Training and documentation reflect the version being released.

Record the differences found in the pilot before turning its configuration into a global template.

Maintain the system after launch

Agree a change rhythm with central and local owners, and assess dependencies before modifying shared properties or workflows. Named roles make that rhythm hold:

A successful rollout leaves teams able to work and administrators able to explain the system. The useful measure is operational reliability across markets, alongside adoption and reporting quality.