When a user logins into the Atlas Portal this is logged to the Activity Feed.

This feature would allow to better user auditing and identify potential security breaches.

This would allow a Private Endpoint to connect FROM an Atlas Project TO a customer's VPC/Vnet (using AWS PrivateLink or Azure Private Link), for accessing private services like a private webhook for alerting, LDAP, and/or KMS

What is the problem that needs to be solved? As a user (MongoDB Driver) you'd like to check revocation status of X.509 certificate via TLS Certificate Status Request extension (also known as OCSP stapling) instead of doing outgoing HTTP connection to OCSP endpoint from a user (MongoDB Driver) side.

Why is it a problem? (the pain) [MongoDB Server v. 4.4.X introduces OCSP stapling functionality](https://docs.mongodb.com/manual/release-notes/4.4/index.html#ocsp), however OCSP stapling is not enabled on Atlas Clusters with MongoDB Server v. 4.4.X.

We have a need to rename our databases as we sync them over to Atlas. However, mongomirror doesn't support that. So that leaves us with mongodump and mongorestore but our databases are large enough that we can't take the outage window necessary to go down that path. When will mongomirror support renaming databases during the import process?

What is the problem that needs to be solved? Customers are willing to troubleshoot / analyze Atlas BI Connector logs by themselves (they would like to investigate schema sampling timings, SQL/MongoDB query optimizations, connectivity issues, etc.).

Why is it a problem? (the pain) Currently available Download Logs option on Atlas Clusters does not include Atlas BI Connector process logs.

Many teams put their databases in subnets without internet access or with just a NAT gateway. It would be great if the Live Migrate could be use through already configured VPC peering connections.

Customer would like replica set tags added to the invoice as a column, in order to further categorize costs. In some instances, the customer has multiple products assigned to a single cluster, and putting the product name in the cluster won't suffice.
The current solution is to use the Invoice API, and then call the Cluster API, in order to programmatically build out a CSV containing the cluster tags as an additional column in the CSV.

I did a live migration from mLab to Atlas quite recently. Although, the steps for migration were simple and easy to execute it took me alot of time to get over the fear of migrating without losing any data. A tutorial video of the entire process would have calmed my nerves and helped me take a lot less time in the process.

We're using Atlas to store PII (HIPAA), and we need to store the log files for an extended period of time, but we don't want any PII / HIPAA data to be stored in the logs.

allow multiple Atlas CIDR (VPC Region) in the same project and allow attaching each cluster to the desired vpc.

today in order to have multiple vpcs in atlas (for example dev &prod)
they need to be separated projects, that create a lot of duplicated work and settings

Prevent the same VPC Peer CIDR block, is it currently possible to have 2 projects with same CIDR block, which requires us to delete our clusters and peer before creating new clusters

There should be a way to prevent them from having same CIDR block or the ability to change the CIDR block AFTER they are created

It would be really usefule to have the ability to create and update database triggers via the API. Currently, updates to triggers cannot be integrated into our testing and deployment process because the only way to update them is manually through the interface.

Include cluster node information for all nodes in the cluster in the response JSON for the getOneCluster API call. As hostnames are needed for other API calls, there ought to be a better way to get cluster node names.

Allow multiple billing e-mails instead of just one. There are multiple people in our org who want a copy of the invoices, but I don't want them sent to the entire org (which is what happens if there's no billing e-mail)

Give an option to pause the cluster as a parameter for specific duration of time, at the moment it is auto activating after 30 days of cluster pause which is not required for all the users and manually we have to keep an eye on this at the moment.

We can specify date format but the time format is limited to 12hr clock. Please allow us to specify 24hr so the activity log and rest of the UI is a little easier to read. Thanks

It is possible to link multiple orgs to each other. It should therefore be possible to use a single API key to access all linked orgs.