Our CI jobs take way too long (1000+ tests) despite heroic efforts to use ApexMocks. As our org contains a bunch of unmanaged packages with known class name prefixes, and these constitute at least 10% of the total tests; we could get back 10% of our life if we could exclude these from the "run only your tests"

For example, we would want to exclude running any tests in classes that start with "fflib" and "sfab"

A variation of this would be to run a specific testSuite and it would be our responsibility to keep the testsuite up to date

With GDPR, companies are required to provide justifications for all data that they collect. In Salesforce this means being able to identify why all fields in the system exists, categorize fields as PI, and provide business justifications. The ability to keep a list of current fields in a production instance of Salesforce that includes alerts when new items are added, or ability to sync that list out to another tool like Smartsheet, where other business users like a legal team would have visibility, would be incredibly useful.

Use case:

1. Deploy from source to target
2. Some testing (or possibly PR review) in target requires fixes to be redeployed from source to target

Currently, you either do a new Comparison or clone the Deployment and re-enter the source and target. In either situation this is tedious.

Why not add a "Redo" button on the Deployment History that uses the same source/target? Place it next to the Clone button?

Or, in the Clone button, default the source and target to the same as the selected Deployment? (which would also be useful)

The XML that comes from Salesforce is weirdly bundled together. When changes are made it's really hard to reconcile two branches in source control when merging.

When comparing, Gearset nicely decomposes changes into smaller chunks. So instead of putting that back into the usual XML, an option to store that "internal format" and even just stick it as JSON or similar.

After all - it'll be Gearset reading it back in to compare to an org next time, and smaller changes will be easier to merge as they won't conflict inside horrendously large XML files

Currently, if source control is either source or target and User A creates a draft deployment bit user B wants to refresh that draft deployment, you get an error message: "Error occurred during operation: Determining API versions - An unknown error occurred."

As this capability isn't currently supported by Gearset, there should be an error message when the refresh comparison button is clicked saying" Refresh is not possible when Source control is involved except by original creator of the draft deployment"

When I do a deployment that is not a CI deployment, it can send an email. But the email goes out regardless if the deployment is successful. I would like to be able to send the email ONLY if the deployment is successful.

Currently, when you rename existing picklist values in the source org (including renaming the API name of that value), Gearset will deploy this to the target org as a new picklist value and deactivate the old value. This means we have to manually delete the value in the target org and specify which value to use to replace on existing records.

It would be great if Gearset could give the option to map a picklist value in the source to a picklist value in the target and allow a rename of the value in the target.

Sometimes metadata comes back from Salesforce in a different order, which makes it look like there was a change when there really wasn't any. It would be nice to have a way to flag such comparisons as Ignored so I know I looked at them and decided that they didn't need to have any further action.

the namespace if referred in code, we try to deploy to target Org, the target Org will not have the same namespace name, or will be a different namespace, it gives errors, can something be done to fix this?

I noticed that the non-XML option label changes depending on what type of object I'm looking at. Regardless, if I select the non-XML option in comparison mode, I'd like the site to remember that option during my session so I don't have to keep re-clicking the non-XML option for each line item.

If you have a piece of metadata that was changed on a comparison then a subsequent comparison using the 'Refresh Comparison' button. The selected item is still selected and unable to be deselected.

For monitored environement, it would be great to have the ability to search for specific item history.

we believe that if we are given the option to filter only permission sets for the comparison, there should be some type of validation ensuring that you are also including dependencies such as custom objects, apex classes etc so that we don't make the assumption that filtering permission sets only in the comparison will include all dependencies

Test jobs are only configured on time basis. When developer commit some changes and it will be deployed, but tests will be done on a time basis in 2 hours for example, so he should wait to know weather tests are passed or not. Or ask the release manager to run tests manually. So, this feature is must have improvement.

Support the ability to group org credentials on the Manage Orgs page by a new Group Name attribute. In managing multiple clients with dozens of PRD and Sandbox orgs it would be extremely helpful to be able to group and filter related credentials by client. However, to expand this feature to support multiple use cases, providing a new Group Name attribute (text) which could contain any value would be fantastic!

Thanks for your consideration,
Mike

Not sure this is a bug or a limitation in the V40.0 SFDC Metadata API but it would appear that Custom Metadata Type (__mdt) listviews are not included in the Comparison (default 66). List Views on other Sobjects are included. Hence they can't be deployed

When a dev team work on a shared deployment, it would be nice to work on the same deployment draft, at the same time. At a bare minimum, it would be good to be warned that someone is updating the draft at the same time as you.