It would be useful to have a "Test Alert" button for each configured alert in order to integrate and test alerts with third-party systems. Otherwise, it is difficult if not impossible to determine what the alert will look like until it is triggered.

Add third-party service integration for Microsoft Teams, as we do for Slack.
Most likely the following can be leveraged to achieve the integration: https://docs.microsoft.com/en-us/graph/teams-proactive-messaging

Streaming snapshots during a restore from a blockstore out to the MongoDB Agent cases the RTO (recovery time objective) to grow linearly with the compressed datasize in the largest shard/RS of the snapshot. The RTO of an Ops Manager restore could be very significantly improved by leveraging volume management infrastructure (such as from VMWare) to restore previously acquired snapshots as virtual filesystems (volumes).

In order to test snapshots automatically, create a new job type that allows the Backup Daemon to download the snapshot from the snapshot store, then run validate on each collection.

If any collection fails validation, send an alert to the Backup Admin with the list of corrupted data.

Integration with Rocket.Chat like done in Slack.

Migrating large sharded clusters to a different cluster pre-sharded with different shard keys requires a significant amount of time to balance post-restore.

This is a feature request to restore a snapshot on a per document basis through a mongos. The desired result is a completed restore with collections/documents residing on their target shards.

If you want to catch full scan on collection you could set up alert "Query Targeting: Scanned / Returned > 1".
OPS Manager does not provide any details where it was triggered.
it would be nice to get db/collection/query which caused this issue. Query still can be fast (for example, not many document in collection yet or hardware is idle/fast at the moment) and will not go to slow operation group.

MongoDB Operator can only deploy and manage MongoDB in a single Kubernetes cluster. However, for DR and global apps, it is important to deploy a single DataBase across multiple Kubernetes clusters to allow for DR or globally distributed apps.

Add an Alert type that is triggered if a project has not reached the goal state for certain amount of time.

Enhance the Ops Manager feature for the detecting of broken processes, validating its sanity, so that Ops Manager could "un-break" processes and start regular backups without any manual intervention.

Since MongoDB 4.4 the tools are located in another folder that is not included in the automation agent bash profile:

[root@n1 mongodb-mms-automation]# cat /etc/profile.d/mongodb-mms-automation-agent.sh
export PATH=/var/lib/mongodb-mms-automation/bin:${PATH}

Would be nice to have also the mongo tools in the path

WE have a 4 node replica set and when we removed 2 of the nodes at one time the election process didn't know how to elect a new primary. We would like the election process to accommodate an even number of replica set nodes.

Currently Ops Manager CRD deployment requires configuration using GUI which is a manual step. An option completely define all OPS Manager settings / Org in declarative manner via yaml will be great in building completely automated CI/CD Pipelines

For the purpose of regularly performing backups of the AppDB using mongodump --oplog.

In order to separate replication, client and administrative traffic, servers may have multiple network interfaces using different IP and hostname aliases associated with them.

According to the requirements described on https://docs.opsmanager.mongodb.com/current/tutorial/provisioning-prep/#server-networking-access Automation currently can use only the server hostname defined as hostname -f and cannot use any of the other aliases matching to other IP addresses for the other machine host aliases.

Please add some way to customize which host alias Automation should use as a configuration parameter for the Agent.