Workspace vs organization

Active Reach has a four-layer account model: organization → workspace → location → property. Each layer maps to a real business concept. Pick the one that matches what you’re trying to isolate.

The canonical model

You almost always start with one organization, one workspace, one or more locations, no properties.

When to add a location

Add a location per outlet — any store with its own opening hours, manager, or per-store overrides. Examples:

• A bakery chain with three physical locations
• A restaurant with a dine-in floor and a separate delivery operation
• A retail brand with stores across multiple cities

Each location can pin its own payment merchant, sender mapping (which WhatsApp number it sends from), inventory source, and kitchen / KOT configuration — without re-registering channels. Channels stay registered once at the workspace tier; senders are simply mapped per outlet.

When to add a property

Add a property per SDK install — anything that ships the web SDK or a mobile SDK. Examples:

• Your main e-commerce website (one property)
• Your iOS app (a second property)
• Your Android app (a third property)
• A standalone landing page on a custom domain (a fourth property)

Each property has its own push key set (VAPID for web, FCM for Android, APNs for iOS) and its own in-app messaging surface, but shares contacts, segments, and journeys with the parent workspace.

Multi-brand: use agency mode, not multiple workspaces

Rule: one workspace per brand. One brand per org. If you run multiple distinct brands, you use agency mode.

If you operate multiple distinct brands (e.g. a holding company with three independent restaurant concepts), you create three separate Active Reach organizations — each with its own workspace — and link them via agency mode. One agency org “owns” the relationship to N client orgs.

Why? Every layer that a brand owns — brand identity, loyalty rules, review policy, fiscal config, channel registrations — should be different per brand. Mixing two brands into one workspace would force shared contacts, shared identity graph, shared channel registrations across brands the provider treats as different businesses. The product model routes all multi-brand operators through agency mode. See the agency overview.

Agency-mode operators can still see all their brands from one cockpit, and switch between them via the Clerk org-switcher in a single session.

The brand-tier defaults pattern

Many settings have a brand-tier value that applies across all outlets, with optional outlet-tier overrides. Examples: bill template, review thresholds, loyalty earning rules, commerce policy.

Brand-tier authoring lives inside each product’s workspace page — there is no separate defaults route. The chip strip at the top of every dashboard page is the scope picker:

• Chip set to “All outlets” → you are editing brand-tier defaults
• Chip set to a specific outlet → you are editing that outlet’s override

Each product page (Active Bill, Loyalty settings, Feedback settings, etc.) renders the brand-tier card only when no outlet is selected; otherwise it renders the per-outlet override editor on the same surface.

Channels are workspace-scoped — never org-tier

You won’t find a brand-tier channels card. WhatsApp numbers, SMS sender IDs, email domains — all of these are registered per business with the upstream provider (Meta WABA, TRAI DLT, your DKIM domain). There’s no upstream concept of a shared org WhatsApp that Meta would allow. So channels live only at the workspace tier, at /dashboard/[workspaceSlug]/settings/channels. Multi-outlet brands map senders to outlets per-location — they do not re-register the channel.

The exception: in-app and push channels are per-property (each property is one SDK install with its own VAPID / FCM / APNs keys).

Write boundaries (security)

Within a single brand-tenant, the “workspace-vs-org” distinction collapses for in-tenant writes — a workspace operator on a workspace page is the brand-tier admin for that brand. The chip-strip’s ?location= URL state determines whether the write lands at brand tier (chip = All outlets, request omits X-Workspace-Id, server routes to NULL-workspace_id rows) or at outlet tier (chip = specific outlet, request carries the workspace and a location_id).

What is still enforced — the cross-brand boundary:

• Agency operators jumping between brands via the Clerk org-switcher cannot mix two brands’ data on one page. The only legitimate cross-brand surface is /dashboard/portfolio.
• A workspace-scoped request that tries to write to an org-tier row with mismatched headers gets a 403, not a silent write.

Shape A vs Shape B substrates

For settings that exist in two shapes — single record per scope vs many records per scope — the UX patterns differ.

You’ll see both patterns across the dashboard. Shape A surfaces look like a form with inheritance toggles per field. Shape B surfaces look like a table with a “Scope” column and a filter dropdown.

Customer URL vs admin URL — the intentional asymmetry

The two URL shapes serve different needs and should not be unified.

Switching contexts

What’s next

• Agency overview — multi-brand and client-managing operators
• Workspace setup — first workspace bootstrap
• Multi-workspace overview — chains with many outlets under one brand