When pushing work flow rules and associated actions, if you do a compare with only workflow, then gearset prompts an error indicating that the target objects do not exist in the destination and that the rules should be removed from the package for the deployment to be successful. In this case, it told me Account, Event and Opportunity do not exist in the target. Including other metadata from the referenced fields resolves the issue.

When we are selecting source/target we can see the friendly name in the dropdown list.

After the selection is made we can see only the username. It would be easier visually confirm that correct connections are are selected if the friendly name was shown next to the username.

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"

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?

We did a deployment last week and noticed that as part of the deployment report that went out that it stated the Tests Run was zero. We did a pre-validation the day before where we ran all tests with all passing.

Could this test section on the deployment report again include/include the pre-validation tests that were run for the deployment?

If a field is identified as missing from the deployment and the user agrees to include it, the corresponding field's permission should also be added.

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.

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

Not sure how you resolve this one without moving either button. Maybe do something similar to what is done in the Diff view (where the action buttons are displayed in a row below the content).

Another option would be to have the live chat in the header navigation to toggle the feature on / off?

Not sure...Just noticed that it gets in the way sometimes.

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

It would appear that in the default 64 comparison set when using Monitor Changes, that SFDC may be returning fieldmappings in non-deterministic order when custom cleanrules are in effect as when Day n-1 org is compared against Day n org, the same cleanrule's fieldmappings are displaced some number of lines away causing a false positive. The obvious workaround is to remove Cleanrules from the metadata to compare but this means one can't detect true variances anymore.

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.

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.

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