This would be an extremely important feature for us. We often run into trouble with version numbers, and then today, an entire deployment was blocked because Gearset did not have a Problem Analyzer to remove incompatible mentions of the IsotopeSubscription standard button from custom object XML.

That would be a great feature to have. Editing XML while deploying reports with bucketed fields would solve the "Required value missing - sourceValue" issue.

Yes I would like to have this feature too for simple fixes.

Please merge this idea with https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/14808303-allow-source-metadata-to-be-customised-prior-to-de

and https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/34886572-allow-editing-on-source-xml

Hello,
its been 3.5 years. Any update on this feature? It introduces a lot of manual work.

This feature is available in tools such as Copado.

Thanks

I'm forklifting an existing org into a fresh org that has no users other than the admin account. This would be super helpful to swap out users set in things like approval processes. Currently you have to download the package and manually swap them in the metadata. It's causing a huge hassle and this feature would be awesome.

YO this would make life soooo much better. I have this exact same problem on every other deployment it seems.

I agree this is needed . In our case we have outbound messages ans for the differemnt environment they use different URLs. idealy, rather than just being able edit manaully we would like to be able to set a variable for the environment that we could then permentantly set for that piece of metadata so that whenever we depoly to that envrioment the variable is used in place of the data from the source org.

This would make layout deployments so much easier.

Hardcoded values (thinking email alerts that don't have the same address amongst orgs) being able to be modified on the fly.

Is this still under investigation? It would be great to be able to have the editor unlocked instead of having to drop to git to do manual modifications for things like emails, URls, etc.

Would also be of use if the editing capability includes functionality to search/replace text through-out the package. Use case: deploying custom fields that include hard-coded text values e.g. URLs. Be great to be able to scan a package for that text string and replace with a value appropriate to the target org.

Is possible to snip out parts of a source XML file during a compare and deploy run?

I have a file that's changed in both orgs and I just want to import the new bits from one org into the other, rather than delete what's new in that second org.

Allow cached metadata to be changed during target deployment after seeing the difference. This will help us to fix environment specific item. This will specifically allow us to fix report folder, dashboard folder etc where the user in source org is not destination org. This will help us fix deployment issue with this tool rather than going back to Ant to fix such metadata during deployment.

I had a situation where a salesforce bug replaced a lookupFilterFields name with an ID, which consequently made a deployment fail. As search layouts are packaged w/the object, there was no way to remove this reference. I eventually solved the problem by examining the xml file in eclipse and deleting the offending field from a search layout but this was potentially a showstopper that could have been solved quickly if I could have edited the object's xml representation.

This is a great idea, and we recently ran into a use case where we had to migrate from a new Summer 17 Release, to an old Spring 17 release (in sandboxes). This resulted in some errors since some settings and metadata just didnt exist in the Spring 17 box, preventing us from moving things like Search Settings, OrgPreference settings, and even a lightning record page. Being able to edit the XML directly in Gearset and rip out things in the deployment to the target org, instead of manually doing it with ANT. +1 to this feature.

another good use case for this is email2case settings. In sandbox, the routing address might by sandbox-support@mycompany.com but in PROD the routing address is support@mycompany.com.

I agree that this would be a great feature. Instead of updating the metadata directly, maybe something similar to that of token replacement would be a good way to achieve this. There could be a list of configuration variables / values for each ORG that for replacement that is leveraged just before validation.

Hi Paul,

I've dropped you an email to follow up about this feature and the requirements.

Thanks,

Stephen

In order to support a development pipeline (e.g. Dev Environment -> Staging Environment -> Production) allow Metadata from the source Org to be modified before deployment to the target Org.

e.g. I have a RemoteSiteSetting in source that points at https://dev.example.com and in my staging environment I need this to point to https://stg.example.com