How Global Teams Manage Segmentation in SFMC

‍

A segment that works cleanly in one market rarely works in all of them.

Global marketing teams run Salesforce Marketing Cloud across many regions, brands, and business units at once. Each one carries its own audience, its own rules, and often its own data.

Segmentation is where that complexity becomes visible.

‍

The mechanics look identical everywhere. You apply criteria to a data extension and you get a targeted audience.

The hard part is doing that consistently when dozens of people, in different countries, build against one shared account.

‍

This guide walks through how global teams structure SFMC, share data across business units, and keep segmentation logic consistent without slowing every market down.

‍

Why global segmentation is harder than it looks

‍

The multi-market reality

A local team segmenting one audience has a simple job. A global team is really running many of those jobs in parallel.

Region A wants engaged openers from the last 30 days. Region B wants everyone except recent purchasers. The logic overlaps, but the data and the exclusions differ.

‍

Without a shared structure, each market quietly reinvents the same segments in slightly different ways.

Multiply that across ten regions and two dozen campaigns, and consistency becomes a full-time problem.

‍

The shared-versus-local tension

Some data belongs to everyone. A global suppression list, a master profile, a set of consent flags.

Other data is strictly local, and sharing it across markets would break privacy rules or simply confuse people.

‍

Deciding what to centralize and what to keep local is the first real segmentation decision a global team makes. Every later choice depends on it.

‍

How business units shape the data model

‍

Enterprise 2.0 and the parent tenant

Most large SFMC deployments use an Enterprise 2.0 account. This structure places a top-level parent tenant above a set of child business units.

Each business unit can represent a region, a brand, or a line of business. Users work inside the unit they are assigned to, while shared assets flow down from the parent.

‍

That hierarchy is the backbone of global segmentation. It decides who sees which audience, and where a shared definition can live.

‍

It also sets the ceiling on collaboration. A well-planned account lets markets borrow from the center freely, while a flat or poorly divided account forces everyone to rebuild the same work.

The structure you choose early tends to outlast the people who chose it, so it is worth getting right before the first campaign ships.

‍

What lives where

The parent tenant is the natural home for anything that should be identical everywhere.

‍

A useful split looks like this:

• Parent tenant: global suppression lists, shared data extensions, account-wide consent logic.
• Business unit: local data extensions, market-specific campaigns, regional exclusions.
• Shared folders: reusable segments any market can run against its own data.

‍

Getting this split right is what makes segmentation predictable months later, when nobody remembers who built what.

‍

Sharing data extensions across business units

‍

Shared data extension folders

SFMC lets you share a data extension with other business units by storing it in a shared data extension folder.

Items saved in a shared folder become available to every unit that has the right permissions. You can set a data retention policy, define a sharing window, and choose exactly which business units get access.

‍

This is how a global team exposes a single Master_Suppression table to every market without copying it.

One source, many consumers, no duplication.

‍

The sharing window matters more than it first appears. It lets the parent revoke access on a schedule, which is useful when a brand is spun off or a market is restructured.

Treating shared data extensions as governed resources, rather than files anyone can copy, is what keeps a large account clean over time.

‍

Permissions and the deny-over-allow rule

The Data Extension Permissions tool controls what each business unit can do with a shared data extension. You can allow or deny specific actions per unit.

Roles behave the same way. When an allow role and a deny role conflict, the deny setting wins.

‍

For a global team this is a feature, not a nuisance. A market can read a shared audience without being able to overwrite it for everyone else.

‍

Keeping segmentation logic consistent across markets

‍

Central rules, local execution

The goal is a single definition of a segment that each market runs against its own data.

An engaged contact should mean the same thing in every region. If one team counts a 90-day _Open window and another counts 30 days, your global reporting stops being comparable.

‍

Writing shared logic once, then letting each unit point it at local data, keeps definitions honest across borders.

‍

The duplication trap

The most common failure mode is quiet duplication. Ten markets each build their own version of a reactivation segment.

They drift apart over months. Filters change, exclusions get added, and nobody can say which version is correct.

‍

Shared data extensions and shared query logic are the antidote. They give every market the same starting point, so a change is made once rather than ten times.

‍

Roles, permissions, and who can build what

‍

Role hierarchy and custom roles

SFMC uses role hierarchy sharing to grant access based on where a user sits in the account. You can also build custom roles that apply in the top-level tenant and inside individual business units.

A role can be assigned to every user in a business unit, with extra roles layered onto specific people.

‍

For global teams this lets a central operations group hold broad access, while regional marketers get exactly what they need and nothing more.

‍

Edit globally versus edit locally

Shared content can be edited in two ways. With Edit Globally, a change made in one business unit appears in every unit that shares the asset.

With Edit Locally, a market creates its own copy with a separate Customer Key and ID, and the change stays contained.

‍

Knowing which mode applies to a shared audience prevents one region from accidentally rewriting a segment for the whole company.

‍

Where the SQL bottleneck shows up for global teams

‍

One query, many business units

Most non-trivial SFMC segmentation still runs on SQL against data extensions and data views such as _Sent, _Open, and _Click.

A global team needs that same query to work across many units, each with slightly different table names or fields. Small differences quietly turn one query into many.

‍

A rename in one market, a missing column in another, and a query that ran perfectly last quarter fails silently. Someone has to notice, diagnose, and patch it, usually under a deadline.

‍

The language and skills gap

Not every market has someone fluent in SQL. When only a handful of people can write the queries, every other market waits in line.

That queue is the real cost of global segmentation. The data is shared, but the ability to use it is not.

‍

Closing that gap is less about writing more SQL and more about giving every market a faster way to say what it wants.

‍

See QAiry in action

‍

QAiry lets marketers in any market describe an audience in plain language and get production-ready SFMC SQL back, built against the data extensions and data views they already share.

See how it works at qairy.com/product-demos, or try it on your own segments at qairy.com/try-it-free.