Studio 3T’s Role Manager, along with the User Manager, simplifies MongoDB admin tasks like granting or modifying built-in roles and user-defined roles. It also lets you see all the users who have been granted a particular role.
Note that Role Manager does not support MongoDB Atlas.
Watch the video below to learn how to create a new user and grant roles:
About privileges, resources, and actions
A privilege is the foundation of a MongoDB role. It is made up of a resource and the actions that are permitted on the resource.
A resource is where the privileges are applied to, for example, cluster, database, or specific collections within a database. In Studio 3T, you can choose from the following built-in resources:
- Resource: Database/Collection – Choose Database/Collection to define the database and specific collection(s) the user should have access to.
- Resource: Cluster – Use the Cluster resource for actions that affect the state of the system like shutdown, replSetConfigure, and addShard.
- Resource: Any Resource (anyResource) – The internal resource anyResource gives access to every resource in the system and is intended for internal use. Use only in exceptional circumstances.
An action (privilege action) defines what a user can do within a resource, or put another way, the operations allowed on the resource.
See MongoDB’s documentation for a list of privilege actions.
Basics
To open Role Manager:
- Button – Click on Roles in the global toolbar
- Right-click – Right-click on any target database in the Connection Tree and choose Manage Roles
Create a new role
- Open Role Manager and click on Add.
- Enter a name for the new role, ensure that the target database is correct.
- If needed, on the Privileges tab, click Add.
- If needed, on the Resource tab, choose the appropriate resource.
- If needed, on the Actions tab, choose the appropriate privilege actions.
- Click OK.
- Check that everything is correct and click Create Role.
To inherit privileges from existing roles and spare the manual task of adding resources and actions, click on the Roles tab and add the relevant role.
View a role
- Open Role Manager and choose a role.
- Click on View to open the role profile and implement any changes.
Remove a role
- Open Role Manager and select a role.
- Click Remove.
- Click Yes to delete the role.
Find users granted a specific role
In MongoDB, users are defined for specific databases. Each user is then assigned a number of roles that in turn define the user’s privileges.
While MongoDB’s API makes it trivial to list all roles that a particular user has been granted, there is unfortunately no easy way for the reverse case where you want to find all users that have been granted a particular role, i.e. the role’s grantees. Studio 3T makes it very easy to find those users.
List MongoDB roles
First off, connect to your MongoDB server as a user that has sufficient privileges to manage users and roles.
Then, in the Connection Tree, simply locate the database that contains the role. Right-click and select Manage Roles.
Inspect selected MongoDB role
This will open the Roles tab for this database.
Here, you can see all the built-in and user-defined roles created for the database.
Now, simply select the role for which you want to see all the users that have been granted that role. In this example, we’re going to look at the user-defined role rwAdmin.
Click Edit.
List MongoDB users with the selected role
By default, the Granted To tab shows all grantees from the same database that the role is defined in.
In our case, that is Natalie, Paul, Peter, and Richard.
If you want to see all users from all databases that have been granted the role rwAdmin, click Refresh for all DBs.

Modify MongoDB roles
In this view, you can conceptually add new users to this role. For this, click Add.
In the Choose User(s) dialog, you can choose users from any database that you want to add to the role.
Of course, users in MongoDB are not really added to a role. Rather, under the hood, the selected users will be granted the role instead. Click Add to add the selected users.
This article was originally published by Thomas Zahn and has since been updated.