Inline Editing of metadata
Inline Editing of metadata
In order to make our deployment successful we had to download the package, modify the version numbers on the flow definitions, and then compare the local package to the target org. It would be very helpful if we can edit the metadata XML in the UI so we can fix the version numbers.
Hello. A large number of commenters requested the ability to carry out value replacements as part of metadata deployments.
Gearset now offers a feature called Environment Variables that lets you do just that!
It works with both manual and CI deployments and lets you target either a Salesforce org or a Git repo of your choice. And, for a number of key metadata types, you can even specify the exact 'field' where the replacement should take place.
If you have any feedback on the Environment Variables feature, please open a new feature request or simply let us know in the in-app chat.
Thank you for upvoting this feature request and we hope that you will find the Environment Variables feature useful.
Alan Birchenough commented
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.
Evans Lacour commented
That would be a great feature to have. Editing XML while deploying reports with bucketed fields would solve the "Required value missing - sourceValue" issue.
Paweł Woźniak commented
Yes I would like to have this feature too for simple fixes.
Martin Kona commented
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.
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.
Ben Nightingale commented
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.
Eric Kintzer commented
Richard Scott commented
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.
I've dropped you an email to follow up about this feature and the requirements.
Paul Mackintosh commented
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.