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?

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.

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.

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

Hey guys,

I am not sure if this is an actual issue or not but I will ask the question to see if I am missing something :)

When comparing email templates, the compare will return both email templates and folders. I have noticed that in my case, email templates that are part of a managed folder do not return. We can see the folder and sync the folder settings, but no templates. If we move the templates to a non-managed folder we can see the templates. Has anybody encountered anything similar?

Thanks!

Richard

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.

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.

When I link my Salesforce org with Gearset, I like to use OAuth as that provides the best security.

Whenever there is an error during the linking process, such as when:

1. The app is blocked (OAUTHAPPBLOCKED)
2. I press Deny on the OAuth consent screen
3. The org has IP restrictions in place that prevents Gearset from completing the OAuth flow

Gearset returns to the Manage Orgs or Configure page without showing me what went wrong!

Filter deployment history & automated jobs to only show a specific team member's activity (e.g. mine). With large teams, the history pages can get too busy and makes it difficult to find the results I'm interested in.

I refreshed a sandbox. I need to re-auth my orgs. I go to Manage Orgs, and sort by my friendly name. I click re-auth, and OAuth is successful and the app tells me I did a good job. But the page it returns me to is using a different sort then I left the page with. ie, it sorts the list by username again. Just extra button clicking I'd like to get rid of if possible. I have to re-auth orgs all the time.

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.

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. :)

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.

Edit "Existing Saved Filters" on an "Existing CI Job"

If using a saved filter on CI job, there is no easy to update an existing saved filter from the CI job directly.

Here is my current workflow:

Start a new compare and edit / save the filter from there, then going back to the CI job, refreshing filters and reselected the saved filtered.

If multiple CI jobs are setup it's easy to miss some jobs which are dependent on updated filter.

Alternative solution - Provide toggle to update all related CI jobs which use the filter.