Business Units

Business Units divide a single Marketing Tenant into flat, isolated data scopes. Each brand, dealership, region, or team works inside its own scope — its own Pages projects, email templates, campaigns, forms, subscriber lists, and documents — while the customer continues to administer one account, one contract, and one identity configuration.

What problem do Business Units solve?

Many Stack9 Experience customers are not one business. They are a dealer group with fifteen dealerships, a franchise with regional marketing teams, or a holding company with several consumer brands. Those groups need real separation of content and customer data, but they do not want fifteen tenants, fifteen bills, and fifteen sets of credentials.

Business Units give you the middle ground:

• ✅ Isolation where it matters — campaigns, forms, submissions, page projects, and files belong to exactly one Business Unit and are invisible to the others.
• ✅ Central governance where it helps — approved templates, brand assets, and the shared component library stay tenant-owned and readable everywhere, without handing every unit edit rights.
• ✅ One account, many scopes — a user with reach into several Business Units switches between them with a selector; everything they see and create follows that selection.
• ✅ Adopt incrementally — there is no platform flag to enable and no migration to run. You adopt Business Units by creating them.

Core concepts

Stack9 uses these terms precisely. They are worth learning, because each one draws a different line between who owns a resource, who may read it, and who may administer the account.

Term	What it means
Marketing Tenant	The top-level customer account and the primary data-isolation boundary. One customer is one Marketing Tenant, no matter how many brands or dealerships it contains.
Business Unit	A flat, subordinate data-access scope inside one Marketing Tenant — for example, one dealership. It is not a tenant and not an organisation. Business Units never nest.
Default Business Unit	The single Business Unit present in every Marketing Tenant. It owns legacy data, any resource created without an explicit Business Unit, and everything in tenants that never created additional units. It is an always-present compatibility boundary, not a mode. The Business Unit itself cannot be renamed or archived; the grant to it is ordinary and removable.
Business Unit Grant	The explicit association that gives one Tenant Membership capabilities inside one Business Unit. A membership may hold many grants.
Active Business Unit	The Business Unit currently selected for a user's requests. The platform accepts the selection only when the membership holds an active grant for it, or holds tenant-wide reach.
Tenant Owner	A Tenant Membership whose reach is the whole Marketing Tenant: it reaches every active Business Unit without holding a grant for any of them. It is a scope, not an administrative role — it confers no authority to administer the tenant or change memberships.
Tenant Membership	An identity's explicit association with one Marketing Tenant. One membership can hold grants for many Business Units and move its Active Business Unit between them. Memberships are created only by explicit assignment.
Tenant-owned Resource	A resource owned and governed centrally by the tenant and made available for Business Units to consume, without transferring edit authority. Examples: approved templates, brand assets, Core Slice definitions, the Shared Asset Library.
Business Unit–owned Resource	A resource owned immutably by exactly one Business Unit. Ownership cannot be moved; to place a copy elsewhere you create a distinct copy in the other Business Unit. Examples: dealership campaigns, forms, page projects, submissions, local files.
Resource Availability	The set of scopes allowed to consume a resource, which is separate from the scope that owns and edits it. Availability never implies shared ownership.
Shared Asset Library	The tenant-owned Documents Manager scope that every active Business Unit may read and select from. Only a membership with tenant-wide asset authority may modify it.

Field naming

Tenant Owner is stored and transmitted as the boolean field is_tenant_admin. The wire name overstates what it does: it grants reach across every active Business Unit, not the ability to administer the tenant. Lead with "Tenant Owner" in your own documentation and integrations.

How scoping works

Every scoped resource carries an owning Business Unit. When that field is empty, the resource is owned by the Default Business Unit — which is why existing data needs no migration and legacy storage keys never change.

Three rules apply uniformly:

1. Reads return a union, narrowed server-side. A user sees rows in the Business Units they are authorised for, plus tenant-owned (shared) rows, plus Default-owned rows when Default is authorised. The scope filter is nested beneath any filter the caller supplies, so a caller's query can only ever narrow the result — never widen it.
2. Writes are authorised against resolved authority. The platform re-derives what the signed-in membership may reach on every request and validates the write against that, not against anything the browser asserted.
3. Ownership is immutable. You cannot reassign a resource to a different Business Unit. Sharing across units is done by duplication — an explicit new resource in the target unit.

Enforcement is server-side and fails closed

The Active Business Unit a browser sends is only ever a proposal. The platform authorises it independently on every request against the signed-in membership's grants. A tampered value can never widen access.

If configuration is missing, no identity subject is present, or an upstream authority lookup fails, the resolved authority set is empty and the request returns nothing — the platform never falls back to "no constraint". An outage that leaves authority undetermined is kept distinct from an explicit denial, so users are not told they have lost access when the real problem is availability.

Because authority is re-read per request and never cached across requests, a new grant or a revocation takes effect on the member's next request. Nobody has to sign out and back in.

Scoping across the products

Area	How it is scoped
Pages projects and documents	A project carries its owning Business Unit, set once at creation and immutable afterwards. Editor requests carry the Active Business Unit inside the signed request scope rather than in the request body. Cross-unit sharing is by project duplication into a target Business Unit, with a preflight that lists private file references that would block the copy. Template projects are tenant-owned: readable from every Business Unit, editable only with tenant-wide authority.
Documents Manager (files)	The most fully built model. Every file and tag carries its Business Unit plus a shared marker. Reads are own unit ∪ Shared ∪ Default (when authorised). A file may only reference a tag that is shared or in its own scope. Storage and cache keys are partitioned per scope; tenants that only ever use Default keep their original unprefixed keys. See Documents Manager.
Campaigns and emails	Business Unit–owned. Campaign lists surface and filter on the owning Business Unit, and emails belong to their campaign.
Forms	Business Unit–owned, with the owning unit surfaced as a filterable column. Form themes can be tenant-owned and shared.
Form submissions	Inherit the Business Unit of the form that produced them.
Subscribers, lists, and audiences	Scoped through the list or audience that owns them.
Slices and Blocks	A Core Slice is tenant-owned and consumed by every unit; a Business Unit Fork is a separate, unit-owned definition. See below.

Enforcement maturity varies by product

Pages and the Documents Manager have the deepest, most heavily tested scope enforcement. Campaigns, forms, and email surface Business Unit ownership and filtering today; if you are designing a compliance control on top of Business Units, confirm the exact enforcement guarantees for those areas with your Stack9 delivery team before you rely on them.

Switching the Active Business Unit

The switcher offers only the Business Units the signed-in membership is authorised for and that are active, with the Default Business Unit listed first. The list comes from a server-side discovery call — the browser never invents it.

When a user switches:

1. In-flight requests are invalidated. Every request is stamped with the selection generation it belongs to, and stale responses are discarded, so results for one unit can never render after a switch to another.
2. Open editors are exited, not retargeted. An open Pages editor navigates back to project selection and its draft is unmounted. Unsaved edits are reported as discarded — never silently saved into the newly selected unit.
3. Authority is re-checked. The selection is a preference; authority is resolved again on the server for every subsequent request.

Unsaved work is discarded on switch

Switching the Active Business Unit intentionally abandons unsaved editor state. This is a safety property: it removes any possibility of content authored for one brand being written into another. Train editors to save before switching.

Do not confuse switching the Active Business Unit with Tenant Selection — a separate control by which a Tenant Owner who belongs to several Marketing Tenants chooses which membership to act under. Tenant Selection changes the tenant; the Active Business Unit changes the scope inside one tenant.

Core Slice or Business Unit Fork

Business Units change how a shared component library is governed. Stack9 offers two deliberate options:

• Core Slice or Block Definition — the canonical, tenant-owned definition, published for Business Units to consume through its declared content and theme inputs. Every unit renders the same definition identity, and a unit cannot structurally override it. This is how one governed brand system stays consistent across every dealership or brand.
• Business Unit Fork — when a unit genuinely needs structural change, it creates a separately identified, unit-owned definition derived from a Core definition. A fork is a tracked, independent copy: it does not replace the Core definition and does not intercept updates to it.

The trade-off is explicit and visible: consume the Core definition and inherit every improvement, or fork it and own the divergence. There is no third path in which a local edit silently changes the shared library.

For how Slices, Layouts, Wrappers, and Blocks fit together, see Content Management.

Incremental adoption

This is the property most customers care about, so it is worth stating plainly.

• Every Marketing Tenant already has a Default Business Unit. All pre-existing data is Default-owned, so there is nothing to migrate.
• There is no global "enable Business Units" setting. A tenant adopts Business Units simply by creating a second one.
• A tenant that never creates a second unit sees no change. One writable library, no switcher, no shared section, original storage keys, original saved preferences.
• Legacy data keeps reading correctly, because Default is authorised for every authorised member and resources without an explicit unit resolve to Default.
• New memberships start with the Default grant, so shared tenant-wide assets are readable from day one. That grant is a starting point, and it is removable.
• Adoption is incremental at the resource level too. Existing Default files do not become cross-unit shared assets implicitly; a tenant opts specific resources into the shared scope deliberately.

Who administers Business Units

Creating, renaming, and archiving Business Units — and appointing Tenant Owners — is an operator-side activity performed through Stack9 platform administration, not a self-service screen in the customer back office. What customers do control directly is assignment: granting an existing Business Unit to a user from the user settings screen in their own instance.

Model versus implementation

The Business Unit domain model anticipates finer-grained concepts — a Business Unit Administrator role, named capabilities, capability roles, and system role templates. These are design intent, not shipped features. Today, tenant-wide asset authority is carried by the Tenant Owner scope. Do not plan a rollout around capability roles until they ship.

API Reference: the customer-facing endpoints for listing your authorized Business Units and tenant memberships are documented in the Business Units API.

Best practices

1. Map Business Units to the smallest unit that owns its own marketing. A dealership, a brand, or a country team — not a department that shares content with its neighbours.
2. Decide what is central before you create units. Templates, brand assets, and Core Slices belong to the tenant; everything operational belongs to a unit.
3. Keep the Default Business Unit meaningful. It holds legacy and unattributed data; treat it as a real scope with an owner, not a dumping ground.
4. Grant narrowly, and use Tenant Owner sparingly. Tenant Owner reaches every active unit, which is exactly what you want for a group marketing lead and exactly what you do not want for a dealership coordinator.
5. Plan for duplication, not reassignment. Ownership is immutable by design. If a page or campaign needs to exist in two units, duplicate it and accept two owners.
6. Save before switching. Unsaved editor state is discarded on a Business Unit switch.

Real-world example

A dealer group runs one Marketing Tenant with a Default Business Unit for group marketing plus one Business Unit per dealership:

1. Group marketing owns the brand system — Core Slices, approved email templates, and the Shared Asset Library are tenant-owned and readable everywhere.
2. Each dealership owns its operations — its own Pages project, forms, campaigns, subscriber lists, and local imagery, invisible to its neighbours.
3. One dealership needs a different finance-offer layout — it creates a Business Unit Fork instead of asking for a change to the group component.
4. A regional manager covering three dealerships holds three grants and moves between them with the switcher.
5. The group marketing lead is a Tenant Owner, so reporting and template governance reach every active unit without maintaining a grant list.

Next steps

• Content Management — Slices, Layouts, Core Slices, and the governed component library
• Documents Manager — Business Unit libraries, the Shared Asset Library, and asset scoping
• Platform Architecture — how Marketing Tenant isolation sits beneath Business Units
• Webhooks — outbound event delivery, and the Business Unit fields still on the roadmap

---

Business Units let one Marketing Tenant behave like many, with isolation enforced on the server, governance kept central, and adoption entirely incremental.