Architecture
Multi-Brand Multi-Tenant Architecture
Each brand in a group operates with its own isolated data and governance while sharing common underlying infrastructure. Group-level reporting is aggregated across brand workspaces, and cross-brand controls such as shared caps are achieved through a group-level unification layer that sits atop the isolated workspaces, not by merging their data.
This page answers
- What is isolated per brand, and what is shared?
- Does isolating brand data mean each brand needs its own infrastructure?
- Can a group see performance across all its brands in one place?
- Can brands share a control, such as a frequency cap, without merging their data?
Two concerns, separated
A group operating multiple brands needs each brand to control its own data, campaigns and access, without duplicating infrastructure per brand and without losing the ability to see or act at group level. Brand-level isolation is achieved by giving each brand its own workspace; group-level needs (reporting, shared caps, unified audiences) are handled by a separate unification layer that reads across workspaces rather than collapsing brands into one shared data pool.
Workspace architecture
- IsolatedBrand workspace AIts own customer profiles, segments, campaigns, journeys, users and role permissions.
- IsolatedBrand workspace BIndependent of every other brand's workspace in the group.
- SharedGroup-level unification lookupA lightweight lookup table synced across the relevant workspaces, read as shared state for shared caps and offer de-duplication.
- SharedGroup reportingThe Insights agent or API-based aggregation reads across brand workspaces into one view.
- SharedShared platform infrastructureChannels, AI features and integrations, available consistently to every brand workspace.
What is isolated and what is shared
| Layer | Isolated per brand? | Notes |
|---|---|---|
| Customer data | Yes | Each workspace has its own customer profile store and segments. |
| Campaigns and journeys | Yes | Built, managed and governed independently per brand. |
| User access and roles | Yes | Role-based permissions are scoped per workspace. |
| Underlying infrastructure | No | Shared across brand workspaces; a new brand is onboarded without standing up separate infrastructure. |
Group-level reporting aggregation
Insights agent
Queries and consolidates data across brand workspaces into a single dashboard view, a group-level read without opening each brand's panel.
API-based aggregation
Metrics are pulled from each brand workspace via API and aggregated in the group's own reporting or BI stack.
Cross-brand unification for shared controls
Some group-level requirements need brands to coordinate behaviour: a shared frequency cap, or de-duplicating offers so a customer is not served conflicting promotions from two brands at once. Because each brand's data stays in its own workspace, this is achieved with a group-level unification pattern: a lightweight lookup table synced centrally acts as a shared ceiling every workspace can read, and templating logic in each workspace reads that shared state to enforce the rule at the point a message or offer is evaluated. Both reporting paths read the same brand-workspace data; the choice is where the aggregation happens, not which numbers are used.
Governance model
Because isolation happens at the workspace level, each brand retains control over its own users, roles, data and campaigns, while the group retains visibility and coordination through the reporting and unification layers. Day-to-day brand operations stay independent; group functions (marketing operations, compliance, group reporting) get a consistent way to see and act across brands where needed.
In TemasCRM
Every claim is compared with this product: what is live, what is partial, what is planned and what is not applicable by this product's design.
3 Live1 Planned1 Not applicable
- Each brand in its own workspace with its own dataLive
Every workspace is a tenant; row-level security keeps profiles, consents, campaigns and sends apart, and the isolation report proves that no table lacks a policy and no probe leaks a row.
Isolation report - Role-based access scoped per workspaceLive
Users, roles and the navigation itself narrow per workspace and per role; a role in one workspace grants nothing in another.
- Shared underlying infrastructureLive
One API and one database serve every workspace; a new workspace is created without new infrastructure.
- Group-level reporting across brandsPlanned
No cross-workspace read exists; each workspace reports on itself. A group view would need its own authorised, audited route.
- Group-level unification lookup for shared capsNot applicable
A shared state read by several workspaces contradicts the isolation this product files as a legal boundary; frequency caps and offers are governed inside each workspace.
Isolation report