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.
Configure the invite flow, set the Organization admin portal domain, and define how member events invalidate active sessions.
Start by creating the application that will serve as your B2B app, if you do not already have one. In the app's B2B application settings, configure the invite flow, set the Org admin portal domain, define how long invite links remain valid, and choose which member events invalidate refresh tokens.
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.
Choose how members sign in to your app and make sure the login flow can resolve the correct organization.
Before configuring access, decide which authentication model your B2B application will use. Members can sign in through Mosaic SSO Service, Mosaic APIs or journeys, hosted login, or an organization's external IdP using OIDC or SAML.
Whatever model you choose, the login flow must identify the member's organization so the correct B2B context can be applied. Depending on the integration, this can be based on signals such as org_id, email domain, or organization context in the journey.
For the complete conceptual and instructional details of this step, see Implement authentication (B2B).
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 application may need, even if only some organizations will use certain roles. These roles are created once at the 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 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.
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 applications.
In B2B Identity, each external business entity that accesses your application is represented as an organization. At creation time, you associate the organization with one or more 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 allowed role groups and define how that organization's members authenticate.
Once applications, member roles, role groups, and organizations are in place, configure each organization's scope for each linked application.
At this step, you:
- assign the role groups created in Step 4 to each organization
- decide whether the organization inherits the app's authentication settings or overrides them
This is the step where the application-level model becomes organization-specific. It determines which member roles an organization can assign and how its members sign in.
For the complete conceptual and instructional details of this step, see Configure org roles & auth.
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 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 is the final step in the setup flow, because 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.