This page provides the ordered setup flow for B2B Identity. Each step gives you the information you need to understand what to configure and why it matters, then links to a dedicated page for the full instructions.
Create the Mosaic application that serves your business customers, and add a client for it.
Create the Mosaic application that will serve as your B2B app, if you don't already have one, then add a client for it. An application can serve B2B alone: you don't need an existing B2C setup.
For the complete conceptual and instructional details of this step, see Configure app & client for B2B.
Configure the invite flow, set the Organization admin portal domain, define the application's B2B authentication methods, and define how member events invalidate active sessions.
In the app's B2B settings, configure the invite flow, set the Org admin portal domain, define how long invite links remain valid, define the authentication methods members can use and whether MFA is required, and choose which member events invalidate refresh tokens.
The authentication methods you define here are the standard experience every organization on this application inherits.
This step prepares the application for B2B use before you define roles, organizations, and members.
For the complete conceptual and instructional details of this step, see Configure B2B settings.
Define the application-level member roles that describe what users can do inside your app.
At this step, define the full set of member roles your customer-facing application may need, even if only some organizations will use certain roles. These roles are created once at the Mosaic application level and later grouped into role groups.
For each role, you typically define:
- Role name — the display name shown to administrators
- Description — optional context for administrators
- Value — the stable identifier your customer-facing application uses in tokens or APIs
These roles are the building blocks for the role groups you create in the next step.
For the complete conceptual and instructional details of this step, see Define app roles.
Bundle member roles into role groups that reflect the scope each type of organization should have.
Role groups are bundles of the member roles you defined in Step 3. You design them around real business scope, so that each organization can later receive only the roles that match its responsibilities.
For example, one organization might receive a narrow group with only sales roles, while another receives a broader group that includes sales, after-sales, or finance roles.
If you use a parent and child organization model, role groups also help define what parent organizations can expose to their managed children. This lets you control precisely which bundles child organizations are allowed to use.
In practice, this is also where you define the mapping between the parent's role groups and the existing role groups that managed child organizations will later be allowed to receive.
For the complete conceptual and instructional details of this step, see Create app role groups.
Create the customer organizations that use your app and link each one to the relevant Mosaic applications.
In B2B Identity, each external business entity that accesses your customer-facing application is represented as an organization. At creation time, you associate the organization with one or more Mosaic applications. Only those linked applications will be available to that organization's members.
You can also use this step to model a parent-child hierarchy, where one organization manages one or more child organizations.
This step defines the organizational structure. In the next step, you will configure the access scope and authentication behavior for each organization.
For the complete conceptual and instructional details of this step, see Create organizations.
For each organization, assign the role groups its members are allowed to draw from.
Once member roles, role groups, and organizations are in place, set each organization's scope for each linked application: the role groups you assign here determine which member roles that organization can give its members.
Role groups are assigned per organization-application pair, so the same organization can have a different scope on each of your applications. Where organizations are structured as parent and managed children, assign the parent first — the child's picker is populated from what the parent has.
This is the step where the application-level model becomes organization-specific.
For the complete conceptual and instructional details of this step, see Configure org roles.
For each organization, decide how its members sign in.
Every organization signs in one of two ways, and the choice belongs to the organization rather than to individual members: it either inherits the authentication configuration you defined for the application, or it delegates sign-in to its own SAML or OIDC Identity Provider.
Federated access replaces your application's sign-in options for that organization's members rather than adding to them, and it's available only if you enabled it for the application in Step 2.
For the complete conceptual and instructional details of this step, see Configure org authentication.
Add members to each organization and assign their application access and organization-level permissions.
After the organization's scope is configured, you can add its members in either the Admin Portal or the Organization admin portal.
When setting a member, you assign two kinds of access:
- Member roles — what the user can do inside the customer-facing application, chosen from the roles allowed by the organization's assigned role groups
- Organization-level roles — what the user can do in Mosaic for that organization, such as administering members or using the Organization admin portal
This completes the configuration shared by both login models. Member access depends on the application roles, role groups, and organization configuration already being in place.
For the complete conceptual and instructional details of this step, see Set members. Org admins can also manage members directly from the Organization admin portal, without needing access to the Admin Portal.
The shared setup is complete. With organizations and members in place, implement and test the login flow:
- Journey-orchestrated — Build the B2B journeys to apply each organization's authentication configuration and register authenticators using Mosaic-hosted screens. If you chose Self managed (Custom UI), follow Self-hosted SSO UI to implement your screens and organization logic.
- Application-controlled — Implement B2B login with APIs to identify the organization and drive authentication from your application.
If you use Mosaic's member invite flow, also build the invite journey described in Build the B2B journeys, whichever login model you chose.