ANT is unable to change the type on an EmailTemplate from HTML to CUSTOM. To solve that we need to add the EmailTemplate first to the destructive package to have it removed and then add it again with the package.xml
Since this file is not deleted but just changed. It doesn't show up in the deleted items tab.

We should add an option to the "Selected Items"/"Changed Items" list to opt-in for adding that to the destructive.

I would like to get some information from the problem analyzer after a CI Job completes as it seems like if it detects a problem during the job it skips deploying some of the components, like user permissions.

Allow assets with "no difference" to be added to a promotion to allow the same package to be used to both promote as well as sync other sandboxes (without having to manually check if asset was changed in each).

In org monitoring we frequently get notification about changes an the only thing is a change to the order of the XML elements returned.
The XML is virtually the same but the order of elements returned changed from one day to the other.

It makes differentiating "real" changes from those false positives time-consuming.

It would be great if those kind of changes could be ignored or if there was an option to configure the XML comparison behavior for each monitoring job.

Enterprise Users can only "Run Now" Jobs that they own. If the Source and Destination Org are shared, allow other enterprise users to run the job.

Webhooks for CI deployment failures simply say "Deployment failed with (179/180 components deployed)" instead of describing the failure in more detail, including the Object and Error Message

Currently Data Deployments only allow filtering on
[FIELD] = [VALUE]

It would be beneficial to be able to include other logic operators such as:
NOT EQUALS
LIKE
IN
GREATER THAN
LESS THAN

etc.

When configuring a CI job, we need an option to set a deployment to another sandboxe when the deployment or test classes run successfully in the current CI Job.
Ex: when a push to a branch on VCS triggers a CI job to deploy to a sandboxe like QA (with test classes run), we also have the possibility to set an auto deployment to staging sanboxe when the the job on QA passed successfully.

If we can exclude certain things in the comparison filters, all other newly created things are automatically provided with the CI job that uses my comparison filters.

For example, at the moment in "custom filters", if I select the type "custom object" and disable "all elements", I can filter and choose which objects we want to compare.

-> We need the option to invert the filter. To be able to select the specific objects that do not want to compare and deploy (like "Not: regex: waste_ | QA_ | staging123_").

It would be nice to be able to deploy to multiple environments all at once from one source.

In rarer situations where I need to make some manual adjustments to the metadata XML for a deployment, I'd like to be able to download the metadata to adjust it. Today you need to go through a compare, and at the end, you can download the package, but this can be problematic, since you have to choose the target org, there need to be differences, etc.

Instead, it would be useful to just choose the source org, select the metadata items, and save the package, without a target org needed.

This would be extremely useful when dealing with small errors. A quick fix could be made in the source org to a single item, the item could be refreshed quickly and than the deployment could succeed.

The goal would be to be able to run a "mini comparison" in order to add a few components to a deployment that may be hitting an issue because it is missing one or two components. This would eliminate the need to run the whole comparison again.

Option to default to Object View vs XML for metadata types that have it available

When cloning previous deployments, there are may cases where items may have been previously deployed, so the now would show as "No Difference". Currently these items can not be unselected for the deployment. It would be useful to be able to remove these from a current deployment to keep the deployment clean.

When sending an outgoing webhook, I'd like to be able to include if the job succeeded, the name of the job etc.

For large payloads (thousands of artifacts) it can be tedious to try to resolve a few minor issues when 99% of the package will deploy successfully. Having a feature to push stuff that passes validation would be helpful. Included in this in the deployment summary and deployment reports will be a count and list of items that failed validation and were omitted from the package so they can be investigated