There are a few reasons you may want to use a FusionAuth Group.

The first use is to logically group one or more users within a Tenant. Once a User is a member of a Group they may be identified as a member of the Group and retrieved using the User Search API.

The second reason you may use a Group is to manage Application Role assignment. A Group may be assigned roles from one or more Applications, a member of this Group will be dynamically assigned these roles if they have a registration for the Application.

Core Concepts Relationships

Below is a visual reminder of the relationships between FusionAuth’s primary core concepts.

Belongs To
Belongs To
Belongs To
Defined In
Is In


Here are some examples of using Groups.

Grouping Users

If you are performing educational marketing activities and driving self-service signups, you can pull the source of a signup off a URL parameter and place it into the user.data field using a custom registration form. On user creation, you could add them to a variety of Groups based on the attributes of the webinar using a webhook.

For example:

  • Date of signup
  • Online or offline presentation
  • Presenter
  • Version of webinar

You could then use these Groups for cohort analysis later to see which users best converted to paying customers.

This usage of Groups can be similarly performed by the user.data custom data fields. However, with this approach, each Group can have metadata in the group.data field that includes information about the Group and how and why users were placed in it. The use of a separate grouping object with its own metadata can be useful.

Assigning Roles

You could create a Group called Admin, and assign this group the admin role from each of your applications.

A more detailed example:

Suppose the Pied Piper Application has two roles: admin and member. The Hooli Application has one role superadmin.

Richard has a registration in Pied Piper and Nelson has a registration in Hooli.

Finally, there’s a group called Admin Group which has the application roles of admin from Pied Piper and superadmin from Hooli.

If you add Richard to the Admin Group, he will receive the role admin in Pied Piper, but not superadmin (because they aren’t registered for Hooli, so he can’t get the role for that application).

Group Membership In Tokens

Sometimes you want membership information in an access token generated by a login event. This data is not directly available in the lambda arguments.

However, you can do this by using Lambda HTTP Connect to request memberships using the Group API from within a JWT Populate Lambda. Here’s an example of such a lambda.

A lambda which adds claims based on a FusionAuth API.

function populate(jwt, user, registration) {
  var response = fetch("http://localhost:9012/api/group", {
    method: "GET",
    headers: {
      "Authorization": "bf69486b-4733-4470-a592-f1bfce7af580"

  if (response.status === 200) {
    // a successful response as defined in the Groups API
    var jsonResponse = JSON.parse(response.body);
    jwt.groups = jsonResponse.groups;
  } else {
    jwt.groups = [];
FusionAuth Reactor logo

This feature is only available in an Essentials or Enterprise plan. Please visit our pricing page to learn more.

Admin UI

Create a Group

Click on Settings -> Groups from the main menu to add a Group. At a minimum, you must provide a Name for the Group and the Tenant it belongs to.

You may apply Application roles from the various Applications in this Group’s Tenant.

Create a Group

Form Fields


The Group Id.


The Group name.


The Tenant the Group will be scoped to.

Application Roles

The selected Application Roles will be assumed by members of this Group.


Groups can only contain Users, not other Groups.

Groups are always contained within a Tenant, and cannot span Tenants.