B2B Identity — Main concepts

This page introduces the core B2B Identity concepts through a single example. In this guide set, your company uses Mosaic to manage access to a holiday booking platform used by external travel agencies, their staff, and optional branch organizations.

As you read, the holiday booking platform is represented by a Mosaic application, each travel agency is an organization, and agency staff are members of that organization.

In Mosaic, the holiday booking platform is represented by a Mosaic application.

The Mosaic application holds the configuration for the product that external business entities use. In a B2B model, access is always evaluated in the context of a specific application.

In this guide set, the main example is a Retail travel agency that uses the holiday booking platform. For that application, you define the member roles that your product recognizes and the role groups that bundle those roles.

In Mosaic, the Retail travel agency is an organization.

An organization represents one of the external business entities that access your customer-facing application, such as a customer company, partner, branch, or supplier.

You link each organization to one or more Mosaic applications. For each linked application, you also decide which role groups that organization can use.

An organization can optionally manage other organizations.

In Mosaic, the Retail travel agency can be a parent organization, while New York branch is a child organization it manages.

This model is useful when one business entity needs to manage a set of sub-organizations within a controlled scope.

In this example, the parent organization can use a broader role group such as Retail storefront, while the managed child organization can be limited to Retail sales only.

The managed child organization does not define its own application scope independently. It can receive only the role groups that its parent organization was allowed to expose for that application.

In Mosaic, the staff who access the booking platform through the Retail travel agency or New York branch are members of those organizations.

A member is a user who belongs to an organization.

In Mosaic, a user is the underlying identity record, while a member is that user in the context of a specific organization. The same user can be a member of multiple organizations, and adding a member does not necessarily create a new user.

This is why you may see the same person both in B2B Identity > Users and under one or more organizations in B2B Identity > Organizations.

Members access only the Mosaic applications linked to their organization. What they can do depends on the roles assigned to them.

For example, a head-office member in the Retail travel agency might receive Booking agent and After-sales specialist, while a member in New York branch might receive only Booking agent.

Members can be managed by administrators in the Admin Portal or, when allowed, in the Organization admin portal.

Member roles control access inside your application, while organization-level roles control administrative actions in Mosaic. Role groups determine which member roles an organization can assign.

Member roles define what a member can do inside your customer-facing application.

In this guide set, the main example roles are Booking agent, After-sales specialist, and Invoice reviewer. You define these roles once at the Mosaic application level.

Role groups are bundles of member roles.

You assign role groups to an organization for a specific application. This defines which member roles that organization is allowed to assign to its members.

For example, the Retail travel agency can receive Retail storefront, which includes Booking agent, After-sales specialist, and Invoice reviewer. A managed child organization such as New York branch can receive the narrower Retail sales only group, which includes only Booking agent.

When working with parent-child hierarchies, use child-facing role group to mean an existing role group that a parent organization is allowed to expose to its managed child organizations.

Organization-level roles are Mosaic system roles that define what a member can do in the organization itself, not inside your customer-facing application.

These roles control actions such as managing members or accessing the Organization admin portal. There are three, and every organization always has them: Organization admin, Managed Organization Creator, and Organization member.

At a high level, access works like this:

1. You define member roles for the application, such as Booking agent, After-sales specialist, and Invoice reviewer.
2. You bundle those roles into role groups, such as Retail storefront and Retail sales only.
3. You assign the appropriate role groups to each organization.
4. When you add or edit a member, you assign that member the relevant member roles from the roles allowed for that organization.
5. You also assign any required organization-level roles for administrative actions in Mosaic.

This lets you control the maximum scope available to each organization while still allowing each organization to manage its own members within that scope.

B2B configuration is split between two portals:

• Admin Portal: where you define the B2B structure, including applications, organizations, member roles, and role groups.
• Organization Admin Portal: where organization admins manage their own organization within the scope you allowed, such as managing members and assigning allowed roles.

• Setup overview — follow the full implementation flow.
• Configure app & client for B2B — create the application and client, and choose how members sign in.
• Define app roles — define application-level member roles.
• Create app role groups — bundle member roles into role groups.
• Create organizations — create organizations and optional parent-child structures.
• Configure org roles — assign role groups per organization.
• Configure org authentication — decide how each organization's members sign in.
• Set members — add members and assign roles.