Managing multiple brand atlases

A team running more than one brand atlas (an agency with multiple clients, a holding company with multiple brands, a multi-brand operator) has options for managing them in aggregate. This page covers the patterns and what each tier supports.

​

The shape of the multi-atlas account

A single Brand Atlas account can be the brand owner of any number of atlases, each with its own subscription, brand record, team, and tier. The atlases are isolated from each other: a colour in one atlas is not a colour in another. The atlases share:

• The account-level user. Sign in once; switch between atlases from the top-left.
• Account-level preferences. Your display name, time zone, notification settings.
• Account-level billing identity. A single billing relationship with Brand Atlas, with separate line items per atlas.

The atlases do not share:

• Brand record content. No cross-pollination by default.
• Team membership. A team member on one atlas is not a team member on another unless invited separately.
• AI configuration. Each atlas has its own Henry key and its own Oswald enablement.
• Tier. Each atlas’s tier is set independently.

​

Three common shapes

​

1. The agency

A creative studio managing several client atlases. Each client has their own brand owner; the studio holds Editor or Brand Maintenance roles across multiple atlases. Tier mix: clients self-fund their atlases (Keeper or Guardian). The studio is added to each atlas under a maintenance retainer arrangement. Useful patterns:

• A single studio identity (e.g. studio@madeby.wtf) added as Editor to every client atlas. The studio’s work is visible in each client’s brand record’s history.
• Shared internal naming conventions across clients to keep the studio’s mental model consistent.
• A studio-side dashboard (built against the public API) showing recent activity across all client atlases.

​

2. The holding company

A parent organisation owning several brands, each with its own atlas. The parent’s brand team has visibility across all brands; each individual brand has its own brand owner. Tier mix: typically Guardian for the parent brand and Keeper for smaller subsidiaries. Some holding companies put every brand on Guardian for the AI features. Useful patterns:

• The parent’s brand team holds Editor roles across the subsidiary atlases for cross-brand consistency oversight.
• Shared partnership Horizons replicated across multiple atlases when a partnership covers more than one brand.
• A holding-company-wide style baseline maintained in a dedicated atlas the others reference.

​

3. The multi-brand operator

A single team running multiple brand atlases for operational reasons: a campaign brand, a parent brand, a B2B variant, a regional variant. Tier mix: usually consistent across atlases (all Keeper or all Guardian). Useful patterns:

• One brand owner across all atlases, with a small consistent team.
• Frequent cross-atlas referencing (the B2B variant pulls from the parent’s brand record).
• A single MadeBy_ retainer that covers all atlases under a unified scope.

​

Switching between atlases

In the portal, the atlas switcher is in the top-left, next to the brand name. Clicking opens a list of atlases the user has access to. Click to switch. The switcher is fast (under a second). For teams that switch frequently, keyboard shortcut Cmd-Shift-A opens the switcher with a search field.

​

Cross-atlas search

For users with access to multiple atlases, search can be scoped:

• Current atlas only. Default. Search returns results from the open atlas.
• All atlases. Search across every atlas the user can read.
• Selected atlases. Pick the atlases to search.

Cross-atlas search is useful for studio teams checking precedents (“how did we handle a similar partnership in another brand”) and for holding-company teams ensuring consistency.

​

Cross-atlas content sharing

By default, atlases are isolated. For deliberate sharing:

• Manual copy. Export from one atlas, import into another. Slow but works.
• MDX-based sharing. A shared MDX file kept in a central repo, included in multiple atlases. Updates to the file propagate when each atlas’s renderer picks it up. Requires Guardian for the repo-direct workflow.
• Reference Horizons. A Horizon in one atlas can reference a section in another (read-only). Useful for holding-company structures where the parent’s strategy is referenced by subsidiaries.

The right pattern depends on how strong the sharing requirement is. Most multi-atlas teams use manual copy for the small amount of genuinely-shared content, on the principle that brand records are intentionally bounded.

​

Billing across multiple atlases

Each atlas has its own subscription. Invoices are issued per atlas; the customer can opt for a consolidated monthly invoice across all atlases in Settings → Account → Billing → Consolidate. Annual plans on multiple atlases can stagger or align. Common patterns:

• Stagger. Each atlas’s annual renewal falls in a different month, smoothing cash flow.
• Align. All atlases renew on the same date, simplifying budgeting.

Switching between staggered and aligned requires a one-off proration; Brand Atlas handles the maths.

​

Team membership across atlases

A team member is invited per atlas. They can be on multiple atlases with different roles in each. For agencies onboarding many people across many client atlases, the SAML/SCIM integration (Guardian) automates this: a single source of truth in the agency’s identity provider syncs to each atlas’s team membership.

​

Studio-side dashboards

For agencies, a custom dashboard against the public API is the most powerful way to see across atlases:

• Recent Update Requests across all clients.
• Aging requests requiring follow-up.
• Recent brand record changes across all clients.
• Guest Pass activity by client.
• Cost reports (Henry usage where the agency holds the keys).

The dashboard is built by the agency; Brand Atlas does not ship one. Most agencies who have built one use a simple internal page (Notion embed, Retool, custom React) consuming the API.

​

Related pages