Workflows · 8 of 10

One campaign, many markets

A global launch becomes eight regional launches the moment it leaves headquarters — and the global team loses sight of all eight.

In plain terms

Each market’s version of a campaign is its own record, pointing back to the global one, so you can see who opted in, who opted out, and what still needs translating. Keep it all in one workspace unless a region genuinely works a different way.

Two models. Prefer the first.

This is the enterprise shape from section 3, with a Markets or Locales taxonomy. There are two workable ways to model the global-to-local relationship, and they differ in cost, complexity, and the Planning package they need.

Figure 1. Two models for multi-market work. Both live entirely in Planning; the left one is the default.

The default: one workspace, a self-connection

Regional adaptations are Campaign records that point at the master through a Master campaign connection on Campaigns — many regional records to one master — plus a Global / local single-select.

It is simple, stays in one workspace, and rolls up cleanly. Markets that opt out stay visible, with the reason recorded.

The two models, side by side.
Aspect	One workspace, self-connection	Per-region workspaces
How regions relate	Regional Campaign records point at a master through a Master campaign connection, many-to-one	Regional workspaces fed by global record types, with cross-workspace connections to the hub
Package	Any	Cross-workspace connections need Planning Prime or Ultimate; global record types need Plus, or Prime or Ultimate alongside Workflow
Roll-up	Clean — everything is in one place	Works, but every shared taxonomy has to be global
Use when	Almost always	Regions genuinely run different lifecycles

Decide before you build. A record type cannot be moved to another workspace later. Splitting by region “to be safe” and merging next year is not an option — confirm the package and the reason for a split first.

Locale variants

Locale-variant Deliverables connect to the master Deliverable and carry the market, the translation status, and any market-specific compliance connections. They are where the real localization work is tracked.

Multi-market field checklist

0 of 7 added ·

Master campaignconnectionA self-connection on Campaigns, many-to-one: each regional record points at its master.
Global / localsingle-selectTells master and regional records apart in every view.
MarketconnectionTo a Markets or Locales record type, on Campaigns and on variant Deliverables.
Opt-out reasonsingle-line textMarkets that opt out stay visible, with the reason: regulatory timing, calendar conflict.
Master deliverableconnectionEach locale variant points at the deliverable it adapts.
Translation statussingle-selectOn variant Deliverables. The field the rollout check counts.
Local ownerpeopleA variant with no local owner is a flag, every time.

Running a rollout

For a master campaign, create or verify the regional records for each market that opted in.
Create the locale-variant Deliverables and set their translation status.
Surface the markets that opted out and why, and flag variants with no local owner.
Roll up performance summaries by market.

Hand off the Campaigns timeline grouped by market, or the variant Deliverables view.

# Spring 2026 launch — 8 markets

  24 locale-variant deliverables created (3 assets × 8 markets)
  2  markets opted out: IN (regulatory timing), BR (calendar conflict)
  Translation pending: FR, DE, ES, JP, KR, AR
  3  variants have no local owner

With AI in the loop

Machine translation plus a localization brief — tone, cultural caveats, disclaimer flags — can be drafted into fields on the variant record by a Fusion scenario, and the regional lead edits and confirms.

Ask about approved AI vendors first. This is the variant most often constrained by approved-vendor rules for large language models. Ask which models are allowed before you design it.

Don’t do this

Localization by default

Rare outside enterprise multi-market teams. Add locale-aware fields when someone asks for them.

A workspace per region, by reflex

Regional splits fragment campaigns that ladder up to the same global strategy. One Marketing workspace is the default.

Taxonomies copied per workspace

Brands and regions repeated in each workspace drift immediately. Define them once as global record types, if the package allows.

Gated features without the package

Cross-workspace connections and global record types are gated above Select. Confirm the entitlement before proposing them.

Limits worth knowing here

Published Planning limits that affect this build. Adobe revises these, so confirm before you design around one.
What	Limit	Why it matters for markets
Records connected to one record	500	In a multi-select connection outside a hierarchy — a master campaign with hundreds of variants is close.
Records per workspace	Select 25,000 · Prime 500,000 · Ultimate 1,000,000	Locale variants multiply records fast: 3 assets × 8 markets is 24 per campaign.
Cross-workspace connections	Prime or Ultimate	The per-region model is not available on Select.
Connection fields per record type	30	Markets, master campaign, and compliance connections all spend from the same budget.

Sources

Adobe Workfront Planning documentation — terminology, request forms, automations, object limitations: Experience League article index
Planning API reference, versions 1 and 2: developer.adobe.com/wf-planning
Package contents and entitlements: Adobe Workfront product description