--- title: "Multi-Brand Multi-Tenant Architecture" slug: "multi-brand-architecture-in-insider-one" description: "Covers how multi-brand groups use Insider One: separate per-brand accounts, shared platform infrastructure, and cross-brand reporting." updated: 2026-10-20T13:27:05Z published: 2026-10-20T13:27:05Z canonical: "academy.insiderone.com/multi-brand-architecture-in-insider-one" --- > ## Documentation Index > Fetch the complete documentation index at: https://academy.insiderone.com/llms.txt > Use this file to discover all available pages before exploring further. # Multi-Brand Architecture in Insider One A group running several brands needs each brand to keep its own customer data, campaigns, and user access. Standing up separate infrastructure per brand is not the answer. Insider One handles this by giving each brand its own account on shared platform infrastructure. This article explains what stays separate per brand and what the group can see across brands. It also covers where a cross-brand requirement needs scoping with the Insider One team. This article covers: - [What each brand keeps to itself](/docs/multi-brand-architecture-in-insider-one#what-each-brand-keeps-to-itself) - [Customer-level data segregation](/docs/multi-brand-architecture-in-insider-one#customerlevel-data-segregation) - [What the group shares](/docs/multi-brand-architecture-in-insider-one#what-the-group-shares) - [Reporting across brands](/docs/multi-brand-architecture-in-insider-one#reporting-across-brands) - [Cross-brand coordination](/docs/multi-brand-architecture-in-insider-one#crossbrand-coordination) ## What each brand keeps to itself Each brand runs in its own account, also called a panel. Insider One generates the account's Partner Name and Partner ID when it creates the panel. To view and copy them, click **your username** > **Settings** > **Inone Settings** > [**Account Settings**](/v1/docs/inone-account-settings). | Layer | Separate per brand | Notes | | --- | --- | --- | | Customer data | Yes | Profiles, events, and segments belong to one account | | Campaigns and journeys | Yes | Built and run inside the account | | User access and roles | Yes | Roles, product restrictions, and PII access are set per account | | Platform infrastructure | No | Shared across all accounts | User access is controlled through the six InOne roles, described in [User Management](/v1/docs/user-management). Within an account, Group Management narrows which campaigns and analytics a team can see, covered in [Group Management](/v1/docs/group-management). Each account manages its own users, and a person has access only to the accounts they are added to. To give someone access to several brands, an **Administrator** adds them in [User Management](/v1/docs/user-management) in each of those accounts. The same person can hold a different role in each account, for example Viewer in one account and Editor in another. For more information, see the [FAQ about User Management](/v1/docs/faq-about-user-management). If you manage users through single sign-on, set up a separate application on your identity provider for each account to give a person a different role in each one. For more information, see the Multi-domain customers section of [Single Sign-On (SSO)](/v1/docs/single-sign-on). To restrict panel access to approved email domains, see [User Domain Whitelisting](/v1/docs/user-domain-whitelisting). For central identity management, Insider One supports SAML 2.0 single sign-on and SCIM provisioning, described in [Single Sign-On (SSO)](/v1/docs/single-sign-on). ## Customer-level data segregation Customer-level data segregation keeps an organization's data separate from that of other Insider One customers. Here, "customer" means an organization using Insider One, not an individual consumer in a customer profile. Insider One uses segregated databases for each customer and assigns each customer a unique client-side JavaScript snippet to keep data collected on its properties separate from other customers' data. This is a separate layer from the account model described above, which defines how each brand keeps its own data, campaigns, and access controls. Segregated data does not mean separate infrastructure: all customers run on the shared Insider One platform, so a brand does not need its own deployment. For more detail, see [Security Principles for Integrating with Insider One](/v1/docs/security-principles-for-integrating-with-insider). ## Set up an account for a new brand Each brand, country, or business unit that needs its own customer data, campaigns, and user access runs in its own account, or panel, in other words. The Insider One team creates new accounts on request. You can't create an account yourself in InOne. > [!NOTE] > To request an account for a new brand, contact Insider One team. When the account is ready, Insider One generates its Partner Name and Partner ID, assigns the Administrator, and emails the invitation to them. The Administrator then adds the other users in User Management and sends them an invitation. ## What the group shares Every account runs on the same platform, so a new brand onboards into a new account rather than a new deployment. Channels, AI features, and integrations are available to every account, subject to the setup each one requires. Frequency capping is configured per channel inside a single account. See [Advanced Settings](/v1/docs/inone-advanced-settings) and [Email Channel Frequency Capping](/v1/docs/email-channel-frequency-capping). ## Reporting across brands To see performance across every brand, pull metrics from each account through the Insider One APIs. Aggregate them in your own reporting or business intelligence tool. Each account's API credentials are managed in **Settings** > **Integration Settings**, described in [Integration Settings](/v1/docs/inone-integration-settings). You can also query Insider One analytics through the Insider One MCP server, described in [Insider One MCP](/v1/docs/insider-one-mcp). ## Cross-brand coordination Some group requirements need brands to behave consistently. A shared frequency cap across every brand a customer hears from is one example. Keeping two brands from sending the same customer competing offers on one day is another. Insider One does not enforce these across accounts out of the box. A group-level rule of this kind is an implementation pattern built on top of the platform, and the Insider One team scopes it with you. Raise it during implementation planning rather than after launch, because the design affects how each brand's campaigns are built. ## What to do next Each brand gets its own account with its own data, campaigns, and access control, while the group gets visibility by aggregating through the APIs. Decide early which controls genuinely need to operate across brands, since those are the ones that need scoping. ## Related - [User and Group Management](/user-and-group-management-overview.md) - [Account Settings](/inone-account-settings.md) - [Security](/inone-security-settings.md)