Currently Atlas only uses a single (flat) user group which only allows for 1 type of authentication per Organization.

However if Federated Authentication is enabled, the authentication mechanism in Atlas is bypassed for the IdP based on the domain name of the user and the configuration of Atlas Authentication.

This causes a problem if there are multiple groups of users who all share a domain name, some of whom are registered in an IdP, and some of whom are not registered in an IdP (for example users in 2 divisions of the same company).

In this scenario, users who are not registered in the IdP are not able to log in.

Proposed Solution:
Implement User Groups in Atlas with separate configuration settings, so that if 1 group enables Federated Authentication, they will not impact any other groups, even if they all share the same domain name in the user accounts.

Our clusters keeps sending loads of alerts during maintenance times about host is down and similar - it's logical and I understand that those are rolling updates so the functionality of the cluster is not affected. However it's quite unfortunate that host are down for quite a while (20 - 30 mins sometimes) and as we don't want to create unnecessary noise from atlas monitoring we had to bump up our slack and pager duty notification to be fired 30+ minutes. This covers maintenance but out of maintenance this is ridiculously high and we would like to know there is possible issue way sooner than that.

As it's the atlas which is performing all the maintenance work it seems better solution would be to let atlas disable such alerts when entering the maintenance and enable them automatically again when maintenance is finished.

Atlas monitoring is great... but it would be super helpful to see a graph of banked iops. (or an approximation of this)

Suppose my iops limit is 100... and during the night my bank gets fully charged to 5.4MM.
During the heavy loads on my server, let's say my iops jump to a steady 500. This means that I am drawing 400 units from my bank. I can do this for 3.75 hours until my bank is exhausted.

It would be so helpful to see an iops bank balance drawing down during peak, recharging during off-peak... and thus getting insight as to when we need to scale up.

In Performance Advisor, I can see sample queries for each index suggestion.
They are formatted "nicely" for human viewing, but to actually investigate it, one would want to copy it as valid mongodb json, and run it with explain or analyze it in compass, or even just run it in a console to see how long it runs before and after the index addition.
However, there is no way of doing that, and I have multiple times "translated" the good looking ui to a mongo query so I could run it elsewhere.
This is a tedious and annoying thing (especially when you need to handle dates....).
Since you already have the data but chose to display/format it in a "nice" way, you also have the json behind it so please just let me copy it as json (with the proper ObjectId and ISODate or new Date() around ids and dates.

Thank you.

It is often practical to Live Migrate from one Atlas cluster to another Atlas cluster (e.g. to create another staging environment if backups are not enabled on the source, or migrate a production/staging environment to another dedicated project with minimal downtime).

Currently, the Live Migrate modal requires connection details from the source cluster, including the hostname of the primary, port, etc. Validation will fail if there are typos/errors in these inputs.

It would be easier to have a point-and-click option to "Migrate from another Atlas cluster" -- it could be a drop-down menu with names of other Atlas clusters in the project/organization that could be selected. The required connection parameters could then be automatically populated based on the particular cluster. A temporary user with the required permissions could even be created and then removed after the migration is complete.

This could make it easier to start Live Migrations between Atlas clusters, and avoid the need for the user to locate and confirm specific source connection requirements.