When defining Custom Roles it should be possible to use placeholders / patterns (regex ?!?) in the "Database" or "Collection" field. This would allow to setup more fine grained rules and allow to reduce the count of rules to be defined.

I need to employees in operations team access to download backups while still limiting other access rights

On Mongo Atlas we are looking to restrict the user permission in specific cluster within project.

I would like to vote this request, since I hear that from the field that customer would like to have more possibilities to allow/restrict access per particular user/group also for CHARTS specific

We are looking for this feature that will allow our teams to access to the Atlas Query Profiler without also granting at least read-only access to the Data Explorer.

We have many teams with different databases they are managing on a cluster.
Right now, to create Search indexes, they have the permission at the project-level and thus can create/delete Search indexes in ALL databases; not just their own.

@Fuat thanks for the update, appreciated. There was no communication on this ticket therefore your comment sheds some light on the case.

Just to clarify, if MongoDB teams are actively working on it, why do you ask for votes to get further updates on this? Should you not provide updates by default now that the teams are working on this case?

Just to bring some clarity with a public comment: The status of this ticket was updated to Started on Jul 20, 2022 that means the work to address the request started and MongoDB teams are actively working on it. Please vote for this request to get further updates.

Was about to vote for this, but then realised the issue was raised 3 years ago(!) with virtually no progress despite hundreds of upvotes. My conclusion is that this feedback platform does not seem to serve any purpose.

Each member of an organization with "Organization Member" role is able to read the billing details of the organization. This should be restricted. We facing problems with our governance, because each member is able to get details about billing in MongoDB Atlas.

The use-case is to share a dashboard with no ability to read billing informations.

I voted for this but I came to a point where I have to say: it would be much more useful for an organization like ours (regulated) to have policies on an organization level that prevent unwanted settings espacially in App Services (like creating endpoints or allow anonymous authentication or just creating ip access lists .... there are tons of such settings) ... so if I have to decide between having fine grained permissions or policies to prevent unwanted/mistakenly made settings I would go with the second. By the way it seems that Atlas has to do some heavy lifting with the fine grained permissions compared to the time this is an open and whished feature ... ;-)

Ditto what has been said about being able to get granular enough to control app services like Realm.

Our use case: give manager permissions to create and invite new users to projects. For that project owner role is needed. With that role, the manager will have access to all data and this is not least privilege principle

Please include permissions for App Services (realm). Right now if you want to edit/test a function in the realm UI, you have to have owner level permissions. That is not a permission level that should be given to most resources on the project

I would like to be able to assign the roles at the cluster level within the project, so that right team members can access to the right cluster in the project instead of getting access to every cluster in the project. Creating multiple projects to resolve this issue causes the burden on network that organization have to dedicate big subnets for getting just 2/3 clusters per project, which ends up in wasting the remaining IPs in those subnets.

That would be helpful to be able to restrict user access to particular nodes/node types.
Real world example:

I want my data analyst to only have access to isolated ANALYTICS node, to not be ably to run heavy queries in operational nodes set and not affect application performance / customers experience.

Also, i need more granular privilege for a user in order to add trigger role.

I'd like to be able to independently set user/team access to support tickets without giving them access to read information within databases.

For our Level 2 operations personnel it would be great to be able to assign a user role that allows for managing alerts, but does not need to be Project Owner role :-)

As per Stanislav : We would like to see Access Control Management as a separate role.