Introducing New Permissions to Creator Group Roles

[peraldon (Jed)]

Hey Creators,

We recently rolled out many new permissions for your Group roles created in Creator Hub. This includes feature parity with many old permissions (such as avatar items, open cloud, and more), as well as some net new permissions around revenue management, assets, and experiences.

As mentioned in our recent Communities announcement, Groups are now the way to manage your collaborations across Creator Hub and Studio, whilst Communities are the way to engage and grow your community.

We continue to iterate on our previous announcement, building out the future of collaboration management for you and your team. This latest launch is a big step forwards, and is bringing the product to a place where we can start safely deprecating aspects of the old system on roblox.com. Take a look below!

New Permissions

You can now give your roles more permissions! As a reminder, these permissions only appear on Creator Hub (choose your group, then find the ‘Collaboration’ tab), and not on the legacy Group pages.

1. Add or remove [role] role members

This permission allows users with the role to give or remove that role to other members within the group. This is a limited version of the existing ‘Administrate all Roles’, for when you want to give someone some management permissions, but not make them a super-admin.

2. Create and configure limited roles

This permission allows users with the role to create, destroy, and configure roles that include only permissions they already have access to. This is a step further than the new permission above, as it means users can administer roles, except the roles that have more permissions than they do. For example, if the user does not have permission to ‘view analytics’, they cannot administer roles that have the ‘view analytics’ permission. It is like an admin permission, but is not the full super-admin permission of ‘Administrate all roles’, which gives users near total access to your group.

3. Play all group experiences

This permission allows users with the role to play all experiences owned by the group, including the private ones.

4. Edit all group experiences

This permission allows users with the role to edit all experiences owned by the group. Note that this permission does not give permission to publish, or insert/upload Group-owned assets. This functionality is in other permissions.

5. Edit & publish all group experiences

This permission allows users with the role to not only edit experiences as above, but also publish experiences to Roblox.

6. View group revenue

This permission allows users with the role to view the group robux balance, any configured recurring split payouts, and in the future, new revenue logging features.

7. Configure group revenue

This permission allows users with the role to not only view all group revenue (as above), but also directly manage it. This includes setting up recurring payouts, as well as sending one-time payouts to collaborators.

8. Configure classic avatar items

This permission allows users to with the role configure the classic avatar items (ie the 2D clothing).

9. Create classic avatar items

This permission allows users with the role to create the classic avatar items (ie the 2D clothing).

10. Manage own Open Cloud API keys

This permission allows users with the role to configure and upload their own open cloud API keys to the group.

11. Manage all Open Cloud API keys

This permission allows users with the role to upload their own open cloud API keys to the group, as well as configure everyone else’s.

12. View development items

This permission allows users with the role to view development items owned by the group (for example, Audio).

13. Create and configure development items

This permission allows users with the role to upload and configure asset development items (for example, Decals).

14. Manage development item permissions

This permission allows users with the role to configure permissions of development items (for example, audio sharing).

Notifications

We also recently launched notifications for group invitations! This means that when you use the new group invite flow, the person you’re invited will receive not only as an email like before, but also as a notification in Creator Hub and Studio.

A note on deprecation

For our new features on Creator Hub, we are starting to hit feature-parity in a number of places (ie roles, revenue management). As a result, you will start to see more banners informing you of the new features, as well as the beginning of some redirects from the old pages to the new ones. We will do this slowly and carefully, as it is incredibly important to us that we do not break user flows.

Our first steps here have been to deprecate the old revenue payout pages, and just redirect you to our new ones on Creator Hub. We have also made it very clear when you manage legacy creator roles that there is a better set of permissions in the new system.

Given this, if you haven’t tried out the new role system yet, we would love your feedback. Now is the perfect time to tell us if something is missing! This means we can make sure we have caught all the edge cases and built them into the new system before moving people over.

The Journey continues…

This is just the next chapter for us, as we continue to overhaul collaboration management. Please give us feedback and requests, we love hearing from you! Next up, just round the corner is -

1. New activity tracker for groups
2. Experience ownership transfer

With so much more as we rapidly march into 2025.

Until next time!

[vltsna]

Well, those are cool new features! I’m glad we have them added now.

[Gavineo]

Love the customizability! Sad to see this is most likely the end of the old group UX. Time to learn a new dashboard.

[colbert2677 (ImagineerColbert)]

Such a thorough improvement to the groups system. I’m very pleased that I can assign privileges to users without having to dedicate entire legacy roles to them in communities where I may not want to or define permissions for special users (for example, out of 15 people ranked “Board of Directors”, only 3 of them have access to edit and publish experiences). Groups are really critical in today’s Roblox.

I’m most excited and hoping for granular per-experience permissions. I understand that current work is directed towards feature parity for developers and working towards the grand vision of separating developer access from the main website, though I’m hoping to eventually see my ability to assign certain permissions (especially edit and play) on an experience-level. That would be the absolute best, so I can keep my experiences visible on my community page but only allow certain qualified players to play without also giving them access to all limited-access experiences.

[peraldon (Jed)]

Thanks for the thoughtful writeup! For what it’s worth, experience-specific permissions using this new system is incredibly high up our todo list for next year

[xRainbowFusionx (FusionPaws)]

Just, wow. This has been needed for a long time. Can’t wait to have proper control over my Developers.

[jackjenningsdev]

Would it be possible to have a separate “manage experience bans” permission? Our current moderation system allows bans through the API but it’s still easiest to handle appeals and unbans through the experiences page. Currently it’s not possible to give our senior moderators access to the Bans portal without also giving other (unneeded) permissions.

[Redusofficial (Redus)]

Are there still plans to add permissions for creation of experience secrets, and if yes, when?

[ChasingSpace (Chasing)]

@peraldon

10. Manage own Open Cloud API keys

This permission allows users with the role to configure and upload their own open cloud API keys to the group.

This is pretty huge, I like this change. Are there any limitations on what permissions they can grant to an API key?

@peraldon

12. View development items

This permission allows users with the role to view development items owned by the group (for example, Audio).

13. Create and configure development items

This permission allows users with the role to upload and configure asset development items (for example, Decals).

Do you plan on having permissions that depend upon or otherwise automatically check off other permissions? I don’t know what the intended behavior of being able to upload and configure items but not view them is.

[DabidarZ (Dabidar)]

just started using this and it works flawlessly, well done

[peraldon (Jed)]

This is a great call out - will take this back to the team to discuss. I can definitely see the use case. Thanks!

[peraldon (Jed)]

1. Right now, there are no limits to the permissions that can be granted to an API key. Let me know your thoughts though, I wonder if that’s something we should limit more…

2. Permissions are use case based - so for this example, you have to be able to view development items to configure them, ergo the ‘create and configure’ permission includes view access on its own. Each permission should be able to stand on it’s own and provide access itself so the role can make full use of it.

[DevSpec (iJava)]

Overall a great step in the right direction, glad to see these new permissions being added.

Are there any plans to create a permission to allow read-only access to the Developer Console in all experiences? E.g. viewing the Server Log, running the ScriptProfiler, etc. without being able to execute code in the Server Log.

This is the main limitation with trying to configure group roles for developers who only need access to test environments but not production - they’re unable to properly debug and analyze performance issues without being able to view the Developer Console, and currently viewing it requires all-or-nothing access to edit the production experience.

[LordMerc (Merc)]

Please make it so people with the Edit Experience permission can view the Monitoring tab. Currently, only group owners can view this tab.

Group I own:

Group I can develop in:

This will allow us to view insights greatly as developers.

[bvetterdays (roman)]

Roblox has truly outdone themselves with groups these past few months, my god

1. What is meant by the upcoming ‘Activity Tracking’ feature? Will this allow us to track the overall stats of the group, or rather users’ activity inside of it/it’s games?
2. Have always wondered if we’ll ever get a “Display role on website” toggle for these new roles. Probably has been asked before but would be absolutely amazing for roleplay groups that really want to start using this new feature (and this is the one thing holding them back) or just for groups that want their roles displayed on the site. This is one of the main features that’s still missing here.

[ChasingSpace (Chasing)]

1. I think it could be interesting to have a “template” key which determines the maximum scopes and permissions that can be granted.

   Otherwise, I think it should at least have a confirmation prompt (similar to the recent luau-execution-sessions changes) about what the permission fully entails and if you’re really sure you want to enable that.

2. That makes sense. It’s not an important point, but something that just improves clarity if a permission basically includes something else that may be actually checked off.

[ChasingSpace (Chasing)]

I think the permissions in your group are wrong. I can see the monitoring tab under a group experience I don’t own.

Do you have the permission to view analytics for group experiences enabled? I believe it’s under that.

[jeziskrista (Crook)]

Cool Update! Appreciate it. Thanks Roblox Team

[IntentionalChaos (Obama)]

I’d also like to build off this feature request. Is there a possibility of, on top of Edit/Play permissions on an experience-level, a way to assign certain roles the ability to read/edit scripts?

As much as I would love to trust new hires, I still fear that a newly hired modeler, for example, could easily just view the scripts, and then steal the code for themselves. Could there be a chance for new permissions to allow viewing script code?

I understand that I could just keep 2 separate places, one for the actual code + map assets, and only for assets; but this breaks my workflow where I need to manually copy and paste assets from one place to another, all because I don’t trust new hires that they won’t steal.

I hope this is being considered in some way or another, as this is a feature I’ve wanted for years now.