I need to run my own tests (ie no namespace) daily as those should never fail and if they do I need to know

For namespace tests, I just need to run them weekly, primarily to reset the "invalid" flag on apex classes that can be tripped by trivial changes. I know some will fail as we have some huge apps installed and my understanding is that it's normal for dome of those managed tests to fail.

So I would only want to run them weekly to reduce the noise from the daily failure email. Just run those on Saturday.

Sometimes my tests are failing when they run during the automated run at night, but, when I log in and run the tests manually, they pass. I can see the failure stack trace, but I was wondering if there is any way to keep/view the debug logs from the failed tests so I can try to understand why they fail at night, but work during the day?

Dependencies with sharing rules. Roles/Groups/Fields referenced in sharing rules may be helpful to add as "dependent" on as if they are not in the destination org you cannot deploy.

In change sets we can pick individual sharing rules to push (specific ones on an object). However through gearset we can only push the whole object.

Manage users on "My Team", so we can activate/deactivate users and then save on licences that are not used until reassigned.

Just a user preference item – when you switch tabs (ex: New Objects to Deleted Objects), it doesn’t place you at the top of the window.

So if I scroll down through all the New Objects and then switch tabs to the Deleted Objects, it just places me in the same relative location as I was in the New Objects tab.

It would be nice to have it reset to the top of each window when I switch tabs.

Would like to be able to quickly select the custom objects and standard object custom fields AND only the related metadata items to make then function correctly (permissions, layouts, field level security, etc..)

Then we could go back and migrate all the process automation stuff - workflow rules, flows, trigger, etc..

It always starts with the data schema first. We need a quick way to see what is different between two orgs and get that synced first

Often you want to deploy Admin profile and (x) custom profiles. Compare and deploy picks up hundreds of entries for standard profiles which are surplus to requirements. A single click way would be veryuseful.

Hello,

It would be very nice to be able to have a test classes suggestion when doing a deployment with "specified test level". The suggestion will ensure the package elements will be covered at least by 75% and so speed up the deployment.

I have multiple slack teams, I'd like the ability to hook up a monitor org, or a test run to send to multiple slack webhook urls.

Not super important, and I suppose I could get around it by scheduling a duplicate, but that just felt wasteful of everyone's API's. :)

When migrating ReportFolders, either remove running user or let me map users between Sandboxes/environments

The SharedTo User doesn't exist in the target org causing my deployment to fail.

I have certain metadata which is broken or dangerous to migrate from a dev org, I'd like to exclude it from this and subsequent releases. If I could 'right click' and ignore it that would be good.

I would find it very useful if the comparison result highlighted if the difference was in the XML or the Code (or both) for each item. This would especially save time when there are a lot of differences.

Some of my orgs have many tests, and I don't always want to run all of them on a daily basis. Being able to specify which tests are run daily would be great.

Being able to export a summary of an org's metadata state for reference, prior to a deployment or as part of our reporting, would be great.

It would be great to be able to select multiple items in a comparison using crtl or shift click, rather than checking the boxes one by one

We have no way of knowing when the files were last changed on the source control side. Tried only with BitBucket though.

Currently, if you try to compare a repository to a Salesforce org, it will throw an error with only the ability to send a report to Gearset if the repository contains files that are not compatible (gulp files, package.json, etc. at the root of the repo or any folder that isn't corresponding to a Salesforce type of file).

My suggestion would be to add the ability for the user to exclude those files or folders from the compare and retry when it fails. This issue currently prevents us to use source control in the comparisons.