Migration complete (Oct 8)
This migration is now complete. All existing and new groups have the unified experience.
TLDR
- Two role systems are becoming one: Your Community and Creator Hub group now share a single role list. Manage it from either surface; changes sync both ways.
- Most of your permissions carry over: Most permissions are automatically migrated, with a few cases where you need to take manual action.
- You can opt in when you’re ready, but migration is forced on October 5: Review and switch when ready. Any group not opted in is migrated automatically by the start of October.
- Most groups will have no breaking changes, but check the breaking changes section to see if you’ll be affected.
- “Rank” values no longer determine who outranks whom: After your group is migrated, they are now set by role order in the list, not rank numbers. Most groups will have no effects from this change until you start changing roles.
- Roles can now be “private” (not visible to the public): Incoming Creator Hub roles migrate as private by default, so they never show on your public Community page or in experiences.
Hello Creators,
We’re making it easier to manage and view permissions in groups. Starting today, you can opt in to have your Community and your Creator Hub group share one unified screen for managing roles and permissions.
We heard your feedback that it was difficult to manage two different role systems, as the list of roles and permissions differed depending on the management screen you were viewing. Now, you can change roles or permissions on either surface and it syncs to the other.
We will migrate all groups automatically on October 5. Most permissions carry over automatically. A few groups have breaking changes that need action first, so check the breaking changes section to see whether yours is affected.
Please visit your group’s management page for a banner that will prompt you to opt into unification. You can read below for more details on what unification entails.
Thanks to @mr_tidum @hoodwinkedsunshine @dimsumbao_pa @ElusiveWind for working on this change!
One Role List, Managed From Either Surface
Today, if your group has both a Creator Hub group and a Community, you manage two separate role systems. After unification, they’ll merge into one:
- Roles and permissions set on Creator Hub show up on your Community page, and vice versa.
- Creator Hub roles initially appear above your Community roles after migration, with relative ordering preserved within each group. If those roles carry kick, ban, or role-assignment permissions, this has implications. (See breaking changes)
- The role limit rises to 100. Groups already over 100 after merging will be grandfathered in.
- Permissions are grouped into three categories: General, Community, and Creator.
What’s changing in the permission list:
Click here to view details
| Current permission(s) | New permission | Change | What it means |
|---|---|---|---|
| — | Manage roles | Added | Create, edit, delete, and reorder roles below your highest role, and edit their permissions if you have this. Includes Assign or remove roles from members. |
| Manage lower-ranked member ranks | Assign or remove roles from members | Renamed | Assign and unassign roles below your highest role. The check is based on the role being assigned, not the target member, so eligible lower roles can be assigned even to someone ranked above you, including the owner. |
| Kick lower-ranked members | Kick members | Renamed | Kick members whose highest role is below your own. |
| Ban lower-ranked members | Ban members | Renamed | Ban members whose highest role is below your own. |
| Create and edit community experiences | Manage access to this group’s resources | Renamed | This is a legacy permission that has many different effects that are not strictly limited to editing experiences. We’ve renamed it for clarity. This permission will be decomposed into more granular permissions in the future. |
| Accept join requests | Invite or approve members | Merged | Combines the old Accept join requests with member-invite actions under one clearer name. |
| View audit log / View group activity history | View audit logs | Merged | |
| Manage own API keys / Manage all API keys / Create community API keys / Administer all community API keys | Manage API keys | Merged | Simpler permission for managing API key permissions in a group. Only set if the role had Manage all API keys / Administer all community API keys, otherwise dropped. |
| Configure and spend group revenue / Spend community funds | Manage and spend group revenue | Merged | Combines the old permissions under one clearer name. |
| Add or remove group members | — | Removed and automatically migrated | Superseded by “Invite or approve members” and “Kick members”. If the old permission was set, these two new ones are automatically set on that role. |
| Administrate all roles / Configure limited roles | — | Removed with replacement | Superseded by “Manage roles”. |
| Add or remove “X” role members | — | Removed with replacement | Superseded by “Assign or remove roles from members”. |
| Grant all available permissions | — | Removed | Does not carry forward in the unified model. The alternative is to manually grant all other permissions. |
Two-factor Authentication (2FA) Required for Sensitive Permissions
Some permissions let members take high impact actions on your group or its members. To ensure the security of your group, you’ll need to have 2FA enabled and pass a 2FA check to grant these permissions to other users via roles:
- Manage roles
- Assign or remove roles from members
- Manage access to this group’s resources
- Manage and spend group revenue
- Delete data stores for experiences
Hierarchy Is Now Role Order, Not Rank Numbers
Which role “outranks” another (for kicking, banning, and assigning roles) used to be decided by each role’s numeric rank value. Now it’s decided by the role’s position in the list: higher in the list means higher authority.
- Drag and drop to reorder roles. Group owners and users with the new “Manage roles” permission can change ordering (below their highest).
- Your highest role is your ceiling: you can only act on roles below it, and only on members whose highest role is below yours.
- When you kick or ban someone, the limit is set by your highest role, not by the specific role that carries the permission.
- Rank values still exist. They keep working in legacy Luau engine APIs and can still be viewed and edited. They just no longer decide who outranks whom on the platform.
Best practice: Going forward, for in-experience or Open Cloud role API usage, we recommend that any privileged functionality based on roles matches a user against a particular role ID(s), rather than checking what the “rank” value is of the user in the group.
Public and Private Roles
Unification puts your internal operations roles (publishing, Creator Hub settings, moderation tooling) into the same list as your public, Community-facing roles. Without special care, those internal roles would start showing up on public Community roles surfaces and in experiences. We want to avoid leaking your private Creator Hub roles, so we’re introducing role visibility as a concept for group roles.
Every role can now be configured as public or private:
-
Public roles are visible to everyone in your Community and in any experience that displays role info.
-
Private roles only appear on the role and permission management surfaces (where you edit roles), never on public Community pages or via the in-game GroupService APIs.
-
Private roles are visible only to group members with access to the group management page.
- Note: This means group members without group management permission can have private roles without being aware of it.
-
Creator Hub roles migrate over as private by default, since they are not publicly visible before unification.
-
Toggle a role’s visibility anytime if you’re the owner or have Manage roles permission.
Modern Engine APIs for Role Fetching
Now that members can hold multiple roles, we have shipped engine API changes for richer, more accurate role data in your experiences.
Use GroupService:GetRolesInGroupAsync to return every public role a user holds, not just the highest, plus whether they’re a member at all (no separate IsInGroup check needed).
GroupService:GetRolesInGroupAsync(userId: number, groupId: number) : {
IsMember: boolean,
Roles: {
{
Id: number,
Name: string,
Color: Color3,
Rank: number
},
...
}
}
- If the user isn’t in the group,
IsMemberisfalseandRolesis empty. - Otherwise
Roleslists every public, non-membership role the user holds, ascending (highest last). - We recommend referencing roles by role
Id. This is stable, unlike rank values or names.
The following Luau APIs will still work, but we recommend moving off them when convenient:
| API | Use instead |
|---|---|
Player:GetRankInGroupAsync |
GroupService:GetRolesInGroupAsync |
Player:GetRoleInGroupAsync |
GroupService:GetRolesInGroupAsync |
role / rank fields in GroupService:GetGroupsAsync |
GetRolesInGroupAsync for roles; GetGroupInfoAsync for ownership |
To read private roles or manage role assignments in-game, we recommend in-experience HTTP requests against Open Cloud to achieve those use cases.
Breaking Changes: Check Before You Unify
Most groups will have no breaking changes. For others, you will be prompted when you opt-in if there are any issues. There are two situations where you may need to take action:
- Creator Hub roles initially sit above Community roles after migration
- If a Community role has kick, ban, or role-assignment permissions and a Creator Hub role has members, those permissions can apply more broadly after migration, because these permissions act through your highest role (not based on the role where you have the permission).
- Action required: during opt-in, review the merged list and reorder or remove permissions as needed. If you don’t opt in by October, we’ll automatically clear kick/ban/assign-roles from those Community roles before migration, to avoid any permission escalation issues.
- Roles sharing the same numeric rank value
- If your group contains multiple roles sharing the same “rank” (this only affects ~1% of all groups), and at least one of those roles have either a kick, ban, or assign roles permission, the behavior of those permissions may change after unification. People in one of these roles may be able to kick/ban/change roles of users in the other role that was at the same rank before, because after unification roles are strictly ordered and cannot be at the same level.
- Action required: The system will highlight affected roles, allowing you to manually resolve ordering conflicts by assigning unique “rank” values. Alternatively, you can allow us to automatically delete the conflicting permissions before migration, which can be re-added afterwards. If no action is taken by early October, these permissions will be removed automatically before migration, to avoid any permission escalation issues.
Changes to Web API Usages
If you use web APIs with your groups, here are the changes to be aware of after your group is unified.
Your Creator Hub roles get new role IDs. Any automation that references the old Creator Hub role IDs will need to be updated. You can look up the new IDs from the Organizations roles endpoints:
- GET https://apis.roblox.com/orgs/v1/organizations/{organizationId}/roles - New role ID is in the groupRoleId field.
Creator Hub web APIs are being retired for unified groups. Once a group is unified, calls under the https://apis.roblox.com/orgs/* prefix will be blocked for unified groups. Move any automation off the /orgs/ endpoints and onto the Open Cloud groups APIs before you unify.
Open Cloud groups APIs honor role visibility. The Open Cloud groups role endpoints will return private roles and their fields according to the new public/private visibility (see section 3), scoped to the caller’s permissions.
We strongly recommend reviewing further information about web API behavior and endpoint changes related to group unification in the separate post here.
How to Opt-in
On the group management page in Creator Hub or any Community configure page, you’ll see a modal to “Unify your group’s roles & permissions”:
- No breaking changes → quick confirmation to opt-in and begin unification.
- Collisions that need attention → you’ll see exactly which roles are affected. You can rectify the permissions as suggested above or confirm you want us to automatically make the outlined changes for you.
If you choose “Ask me later” you will be re-prompted the next day.
After opting in, you will see a confirmation once the unification is complete and you can start using the new unified role and permission system!
Give Us Your Feedback
We’re eager to get your thoughts on the new permission categories and layout, and if there are any gaps in the new or existing engine APIs for your in-experience logic, or any issues using unified groups in Open Cloud automation.
Thanks from the teams working on Groups and permissions at Roblox 
FAQs
Click here to view
Why are you unifying roles and permissions, why not leave it as-is?
- We got feedback from creators that the two systems are very hard to manage, and many creators don’t realize that the Creator Hub-side permissions even existed. By unifying the two, we’re making it easier to manage permissions, and easier to discover the set of permissions that exist. You also benefit from the shared set of features between the two systems this way, rather than having to pick-and-choose. The unified system is also fully compatible with engine APIs and Open Cloud endpoints, whereas before only Community-side roles were accessible via engine APIs and Open Cloud.
What happens if I don’t opt in before October 5?
- Unification will be forced on Monday, October 5. We’ll force unification as safely as possible by removing permissions that cannot be automatically migrated. This ensures there are no permission escalation issues from the unification. We strongly recommend you migrate yourself before October 5 and resolve any breaking changes yourself to avoid any breakage.
What happens if something breaks after I unify / unification is forced for my group on Oct 5?
- Unification will only remove permissions that we cannot migrate automatically or block certain web APIs from working. It won’t grant additional permissions to users automatically. If you notice any breakage to your group’s operations after unifying, please review the information above and adjust your roles and permissions configuration accordingly.
Where can I grab role IDs from to use in engine API or Open Cloud usage?
- At the bottom of every role permissions/settings page, we’ve added a “Copy Role ID” button you can use to easily grab the role ID for use in engine APIs and Open Cloud APIs.