Content Catalog Design: Single, Shared, and Multi-Layered Strategies

Content catalog topology is decided once, early, usually by whoever writes the first ImpEx, and then every content team in every country lives with it. The wrong choice shows up as duplicated homepage maintenance across twelve country sites, or as two marketing teams overwriting each other's staged changes, or as a global rebrand that takes a quarter because every site owns its own header. This guide lays out the three viable topologies, when each wins, and the operational details (restrictions, permissions, workflows) that make them work in practice.

The mechanics underneath all three: WCMS content lives in content catalogs with catalog versions, conventionally Staged and Online. Editing happens in Staged, synchronization publishes to Online, and catalog versions double as the permission boundary for business users. Everything here applies equally to accelerator storefronts and composable storefront projects; headless changes how content is delivered (CMS OCC endpoints), not how it is organized and governed.

Option 1: One Catalog per Storefront#

The accelerator default: each site gets its own content catalog, fully isolated.

electronics-de site  →  electronicsDeContentCatalog (Staged/Online)
electronics-uk site  →  electronicsUkContentCatalog (Staged/Online)

Choose this when isolation is the requirement: different brands with nothing in common, or hard organizational boundaries where team A must never touch team B's content, enforced at catalog level with zero customization.

The cost is duplication of everything, including things you did not think of as content: page templates, headers, footers, error pages, email templates. Twelve isolated catalogs means a header change is twelve edits, twelve syncs, and twelve chances for drift. For multi-country deployments of one brand, this topology is the wrong answer dressed as the easy one.

Option 2: One Shared Catalog for Several Sites#

Several sites read from a single content catalog:

electronics-de site  ┐
electronics-uk site  ├→  electronicsEuContentCatalog (Staged/Online)
electronics-fr site  ┘

Supported out of the box, managed in one place, ideal when a central team owns all content. A global campaign is one edit and one sync.

Site-specific differences are handled through the WCMS restriction system: pages and components can carry restrictions that control visibility by user group, time, category, and other conditions. One honest caveat: there is no out-of-the-box "show only on storefront X" restriction, so shared-catalog projects that need per-site component visibility write a small custom restriction type evaluating the current site. It is a well-trodden customization (a CMSSiteRestriction type, an evaluator bean, roughly a day of work including tests), but it is a customization; budget it.

The topology breaks when multiple organizations edit the shared catalog independently. Two teams staging changes in the same catalog version means their work publishes together or not at all: team A's finished campaign waits on team B's half-built page, or worse, syncs it live. If your org chart has more than one content-owning team, move on to option 3.

Option 3: Multi-Layered Catalogs (Global Plus Local)#

The recommended topology for multi-country, multi-team organizations. Content catalogs form a hierarchy; child catalogs inherit from the parent and add or override locally:

globalContentCatalog          (templates, checkout pages, corporate content)
├── euContentCatalog          (regional campaigns, legal pages)
│   ├── deContentCatalog      (local homepage, DE campaigns)
│   └── frContentCatalog      (local homepage, FR campaigns)
└── apacContentCatalog
    └── jpContentCatalog

The global team owns templates, shared page structure, and corporate pages. Local teams own their homepages, landing pages, and campaign content, in their own catalogs, with their own staged versions, publishing on their own schedule. Nobody blocks anybody. Two layers (global plus local) cover most organizations; regional or channel layers exist for those that need them, and each layer you add is real governance overhead, so add layers only when a distinct team owns that layer.

The inheritance detail that surprises every new content team: a child catalog inherits from the parent's Online version, not Staged. A global template change sitting in global Staged is invisible to every local preview until the global team publishes. This is correct behaviour (locals build on released global content, not work in progress) but it must be part of content team onboarding, or you will field "my page looks wrong in preview" tickets that are actually "global has not synced yet".

Setting up the hierarchy is plain ImpEx:

INSERT_UPDATE ContentCatalog; id[unique=true]; name[lang=en]; supercatalog(id)
; globalContentCatalog ; Global Content ;
; euContentCatalog     ; EU Content     ; globalContentCatalog
; deContentCatalog     ; DE Content     ; euContentCatalog

INSERT_UPDATE CatalogVersion; catalog(id)[unique=true]; version[unique=true]; active
; deContentCatalog ; Staged ; false
; deContentCatalog ; Online ; true

Permissions: Catalog Versions Are Your Access Model#

Whatever topology you pick, wire business-user permissions to catalog versions, not to good intentions:

• Local content editors get write access to their own catalog's Staged version only.
• Nobody edits Online directly. Online is written by synchronization, full stop. Direct Online edits bypass approval, produce Staged/Online drift, and get silently destroyed by the next sync.
• Synchronization rights are granted separately from edit rights, which is exactly the hook approval processes need: editors edit, approvers sync.

INSERT_UPDATE CatalogVersionSyncScheduleMedia... # sync permissions are usually maintained via Backoffice,
# but read access per catalog version is worth scripting:
INSERT_UPDATE PrincipalGroupRelation; source(uid)[unique=true]; target(uid)[unique=true]
; de-content-editors ; cmsmanagergroup

Workflows: Approval Before Publication#

Since 1905 the platform ships CMS workflows integrated into SmartEdit, and they are the difference between "sync rights as approval" (blunt) and an actual editorial process. Two templates come out of the box: page approval, and page translation plus approval. Editors start a workflow on a page; approvers get SmartEdit tasks; the page publishes when the workflow completes.

What to actually do with them:

1. Start with the shipped page approval workflow on the catalogs where mistakes are expensive (production storefront homepages, legal pages). Rolling it out everywhere on day one generates approval fatigue and rubber-stamping.
2. Customize in Backoffice when the shipped flow does not match reality. New workflow templates and modifications are an administrator task in Backoffice; SmartEdit consumes whatever templates exist. Typical customization: a two-step flow with legal review only for pages tagged with a compliance flag.
3. Decide the SmartEdit versus Backoffice question per team. The same workflow tasks surface in both tools. Content-only users live in SmartEdit; teams where the same people manage products and content may prefer running everything from Backoffice's collaboration center.

Choosing, Quickly#

Two closing warnings from projects that got it wrong. First, migrating between topologies after go-live is a real project: pages, components, restrictions, and media references all carry catalog version identity, and moving them is not a rename. Spend the week of analysis up front. Second, topology does not fix governance: a multi-layered setup with no agreement on who owns templates produces the same fights as a shared catalog, just with better tooling. Write the ownership matrix (which layer owns templates, navigation, footers, error pages, email content) into the project wiki the same week you write the ImpEx.