Allowing customers to specify their own S3 buckets for storage could be beneficial for the product. This would give the customer enhanced security and control over their data.

I would like the ability to print the current comparison for selected objects before deploying to use for documentation purposes.

We use Gearset as our primary utility for managing various client orgs include Production and Sandboxes for Testing and Release Management. It would be great if there was also a way to access, review and potentially enable/disable any Critical Updates in any org from Gearset.

However, I do understand that Critical Updates may not currently be accessible from the metadata API.

Just a thought,
Mike

We have a push topic that we use but there is currently no easy way to deploy changes between orgs. Would it be possible to do this via Gearset?

When I remove a page layout from my Git repository (the file and the package.xml entry) and then do a comparison to an org that it still exists in, Gearset fails to detect a deletion. It doesn't even show up in the All objects tab. It happened to me yesterday and then I just reproduced it now.

In the custom filters dialog, if you select a metadata type that is not supported by the API version, the compare and deploy currently just silently ignores that item, giving the impression that the compare has failed. e.g. selecting "Duplicate rule" with metadata version prior to 38.0.

It would be good for Gearset to provide a warning if a selected metadata type is not supported by the selected API version.

I build a VF page, test it, deploy it and discover much later that I forgot to add profiles other than system admin to the page. Users can't see the page and get a permissions denied error.

So, the suggestion is to have a an optional analyzers that warns when deploying a new VF page to a target org where the only permission is System Admin. While this could be legit in some use cases, in most use cases, this is a self-inflicted omission.

I find that I'm frequently copying to the clipboard the friendly name of the deployment into the notes of the next deployment or the friendly name of some other deployment. In addition to the pencil and delete buttons, add a copy to clipboard button

Note I still support other User Voice suggestions like auto-copying the deployment notes from Deployment X to cloned deployment Y or auto-defaulting the friendly name of the deployment from the deployment notes.

My use-case would somewhat be handled by separating code and xml differences, but I would like to be able to filter on difference count (or at least, easily see / sort by diff count).

For example: We are updating the API version on all of our classes and triggers (about 279 files this go around) and I want to make sure that the API update is the only diff when doing a deployment. Or to be worded differently: only deploy files where the only difference is the API version.

If you deploy permissions for, say Task.Type, Gearset deployment analyzer displays: "Exclude the following from the deployment - Field permissions for fields that are probably required fields on the target"

Field Task.Type (V39) is not a required field. If one ignores the suggested exclusion, permissions deploy just fine.

Elimination of spurious analyzer warnings increases utility of the remaining analyzer messages that are the raison d'etre of Gearset

In Chrome, it is possible to display info even when viewing a different tab.

For example, I see this done with financial sites when they want to show the value of a stock ticker symbol.

When you set up notification options for test monitoring, there should be a checkbox for attaching the detailed test result csv file to the email

ConnectedApps are part of the Default 64 metadata set. yet if you try to deploy a ConnectedApp that uses a ConsumerKey in the source org, you will get a deployment error either "The consumer key is already taken" if target org has that ConnectedApp already or "You cannot provide a Consumer Key" if a new ConnectedApp

Since the deployment is going to fail, there should be a Gearset Analyzer that checks for this and removes from the deployment

CustomObject 'Order' Page layouts from orgs created from orgs prior to V39 may have in the layout metadata <excludebuttons>Activate</excludeButtons>

For V39 (and possibly earlier) orgs, 'Activate' is no longer the OOTB API name for the button with label 'Activate'. The button API name is ActivateOrder. Hence, deployment fails with error "In field: excludeButtons, no such standard action:Activate"

There is no workaround except to exclude the Order layout from the Gearset Selected Objects. This is not a good workaround for a commonly-used OOTB SFDC Standard object.

However, the number of differences does appear when viewing the same Apex class in APEX view mode.

When I enable comparing managed packages (e.g. when I have added a field to a managed custom object), I get lots of false positives saying that there are differences in apex code.

On the source org, the code is show as "(hidden)"; on the target it is shown as empty. And Gearset lists this as a change.

Obviously, I know it's not a change, but it adds a lot of clutter to the comparison view.

The background highlight colors for differences are much too light to be able to be seen clearly when viewing in APEX mode. Colors are much brighter in XML mode. Request - allowing these colors to be configurable. Thanks for the consideration.