# Create app role groups

> This page is the **detail** for [Setup overview — Step 4: Create app role groups](/guides/user/b2b/b2b_setup-overview#step-4-create-app-role-groups).
Bundle member roles into **role groups** and — when using a parent–child hierarchy — control which bundles parent organizations expose to their managed children.


## Understand role groups

Use the same **[holiday booking platform and travel agencies](/guides/user/b2b/b2b_main-concepts)** story as in [Define app roles — Understand roles](/guides/user/b2b/b2b_define_app_roles#understand-roles). You already defined the application-level **member roles** for the **Holiday booking platform**. In this guide set, the main example follows one parent organization, **Retail travel agency**, and one managed child organization, **New York branch**.

At this step, you organize those application roles into **role groups**. Each role group is a named bundle of member roles that you will later assign to a specific organization.

In the running example, the parent organization needs a broader bundle for head-office staff, while the managed child organization needs a narrower bundle for branch staff.

Example organization
Member roles in org
Example role group
Retail travel agency
(parent org / head office)
Booking agent
After-sales specialist
Invoice reviewer
Retail storefront
New York branch
(managed child organization)
Booking agent
Retail sales only
This is the same app-level role catalog, but divided into bundles that match real business scope. The parent organization can receive **Retail storefront**, while New York branch can be limited to **Retail sales only**.

## Configure role groups

In **Admin Portal** > **Applications** > your app > **Access control** tab > **Role groups**, select **+ Add role group**.

For each role group, configure:

| Field | Purpose |
|  --- | --- |
| **Role group name** | Required; identifier of the group. |
| **Display name** | Optional; name shown in the Admin Portal and Organization admin portal. |
| **Assigned roles** | Required; one or more of the [member roles](/guides/user/b2b/b2b_define_app_roles) you defined for the application. |
| **Managed (child) role groups** | Only relevant for parent–child hierarchies; the existing role groups that organizations receiving this group can expose to their managed child organizations. See the parent–child sections below. |
| **Description** | Optional; provides context to administrators. |


A member role must sit in **at least one** role group before it can be assigned to members at all.

After role groups are created, they are ready to be assigned to organizations. You’ll complete this in a later step (see [Configure org roles](/guides/user/b2b/b2b_configure_org_roles_auth)).

## Understand parent–child role group relationships

Staying with the same travel booking example, the **Retail travel agency** is the **parent organization** and **New York branch** is a **managed child organization**. Head-office members in the parent organization need the broader **Retail storefront** bundle. Branch members in New York branch should be limited to **Retail sales only**.

This distinction matters because the next configuration step is not only to create role groups, but also to decide which **parent** role groups may expose which **child-facing** role groups. Later, when you configure organizations, the parent will receive its own role groups and the child will be limited to the role groups the parent exposed for managed organizations.

**Child-facing role groups** are existing role groups from the application's catalog that you select as available to managed child organizations.

The **Managed (child) role groups** field does not create new groups. Instead, it lets you choose which existing role groups from the application's catalog can later be assigned to managed child organizations. If no other role groups exist yet, the field shows a message indicating that you must create a group first.

The mapping is **required** for managed hierarchies: a managed child organization can't be provisioned unless its parent exposes at least one role group to it.

A managed child may have **more than one** parent; each parent contributes its own list of exposed role groups.

Travel story
Mosaic
What you configure
The 
Retail travel agency
operates the 
head office
and provisions 
New York branch
as a managed branch.
Organization
(parent)
Give the parent the bundle its own staff need, here 
Retail storefront
. On that parent role group, set 
Managed (child) role groups
to include 
Retail sales only
so admins can attach that narrower bundle to New York branch.
A 
New York branch
employee works with branch-level permissions only.
Managed organization
(child)
On the child, select the bundle exposed by the parent, here 
Retail sales only
. For each 
member
, assign only app-level roles that belong to that group, here 
Booking agent
.
## Configure parent–child role group relationships

The steps below follow the **Retail travel agency** example: create **Retail sales only** for managed branches first, then **Retail storefront** for the parent, then configure the mapping. Assigning the groups to organizations comes later, in [Configure org roles](/guides/user/b2b/b2b_configure_org_roles_auth#configure-role-groups-per-organization-and-application).

In **Admin Portal** > **Applications** > your app > **Access control** tab > **Role groups**:

1. **Create the role groups for managed children**.  You need these groups in the catalog before they can be selected in **Managed (child) role groups**. For example, create **Retail sales only** with **Booking agent** and add the required **member roles**.
2. **Create the role groups for parent organizations**.  Each role group must contain **at least one** member role, including groups mainly used to drive child exposure. For example, create **Retail storefront** with **Booking agent**, **After-sales specialist**, and **Invoice reviewer**.
3. **For each parent role group, expose the role groups that managed children can use**.  In **Managed (child) role groups**, select the existing **child-facing** role groups from step 1, such as **Retail sales only**, that managed children like **New York branch** can receive. If appropriate for your model, you can also allow **All role groups**.


Once role groups and their mappings are in place, they are ready to be assigned to organizations. You’ll complete this in a later step (see [Configure org roles](/guides/user/b2b/b2b_configure_org_roles_auth)).

/* Blockquote intro block */
    [data-component-name="Markdown/Markdown"] blockquote {
        border-left: 4px solid #BBC5FF !important;
        border-radius: 2px;
        background-color: #F1F2FF !important;
        padding: 20px 10px 15px 10px;
        margin: 10px 1px;
    }

    /* Create role groups — bordered example table (same pattern as Define app roles).
       Theme globals set th/td border-left/right: 0 !important. */
    .b2b-wip-table-wrap {
        margin: 10px 0;
        border-radius: 5px;
        overflow: hidden;
        border: 1px solid #ededf2;
    }

    table.b2b-wip-bordered-table {
        border-collapse: collapse;
        width: 100%;
        margin: 0;
    }

    table.b2b-wip-bordered-table th,
    table.b2b-wip-bordered-table td {
        border: 1px solid #ededf2 !important;
        padding: 10px;
        text-align: left;
        vertical-align: top;
    }

    table.b2b-wip-bordered-table thead th {
        background-color: #f5f5f5 !important;
        color: #000000 !important;
        font-weight: 600 !important;
    }

    table.b2b-wip-bordered-table ul {
        margin: 0;
        padding-left: 1.25em;
    }