1122 results found
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.105 votes
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.
Extend the diff tool to allow the user to perform a merge, creating a new version of the component that contains some changes from the source version and some changes from the target version. This would be very useful in a team development scenario where multiple devs are working on features in individual dev sandboxes and then pushing completed features into an integration sandbox.79 votes
Merging differences between Apex classes and VisualForce pages is difficult to do automatically due to the understanding required by the developer. For differences between two orgs in other object types, Gearset helps you sidestep that with our granular comparison results. This blog post explains more: https://gearset.com/blog/merging-salesforce-metadata
It would be great to have more control over the diff process - particularly to be able to ignore whitespace changes.
If I've made an actual function change to a class, and also auto-indented it, then it would be a lot easier to see the important change if I could hide the whitespace-only changes.
Having the ability to suppress whitespace-only changes on the list of changed objects would be really useful, too.67 votes
Thanks for the suggestion.
We have plans to improve the way the diff viewer handles changes and whitespace in the future, though it’s not currently under development.
As Gearset is run through a web browser, if the browser happens to freeze while a package is being built, you don't have the opportunity to save it as a Draft Deployment. An auto-save feature would allow someone to pick up where they left off, or when the last auto-save was done, without having to start from scratch.49 votes
Allow individual lines to be selected for inclusion or exclusion of a deployment45 votes
Gearset now lets you select specific fields in layouts for a deployment.
Here's a quick article on getting started with precision deployments for layouts:
We are working on adding support for more metadata types such as record types, value sets, Lightning pages and other XML types.
create an option to have chained deployments so complex deployments can be broken down and sequentially deployed or slaves can be ran
allowing for multi staged deployments under one CI job39 votes
When using a git repo with a SFDX folder structure + package/xml (in the /manifest folder) gearset dos not take into account elements in the package.xml when checking the option (filter with package.xml)38 votes
It would be nice to be able to deploy to multiple environments all at once from one source.33 votes
I would like to inform Slack on when a manual deployment is successful or failed. It will tell me what the source environment and what was the destination environment. It will also tell me if what the success/fail ratio of the tests that were run.30 votes
Allow assets with "no difference" to be added to a promotion to allow the same package to be used to both promote as well as sync other sandboxes (without having to manually check if asset was changed in each).29 votes
It would be great to be able to copy Territory models from one org to another, as per this request in the SFDC Community...
In most of Tech industry deployment lifecycle, all code or config changes are ideally pushed into production only from a FullCopy Sandbox(Commonly Known as Staging Environment).
It would be very good to have a feature in GearSet App which if enabled shouldn't allow user deploying data from Dev/DevPro/Partial Sandbox into Production Org.28 votes
Integrate with Agile Accelerator instead of just Jira.
It would be great if Gearset (and ideally the Pipelines-feature) could integrate with Agile Accelerator.
Since we're a Salesforce-partner we want to use as many Salesforce-native solutions. That's why we've been happily using Agile Accelerator for many years.
It would be great if Gearset can also integrate with Agile Accelerator instead of just Jira.
Right now the Gearset Pipelines feature isn't useful to us, because of this sole reason.
Thanks for considering this!27 votes
At commit to branch, Gearset reorders large chunks of the XML file. This causes additional deltas (seen in the hundreds of lines) and merge conflicts.27 votes
If you want to deploy new fields and field level security, I want to create a custom filter that hides all profile setting except of field level security and make that custom filter reusable.
Unfortunately RegEx only works on top level elements. In this case profile names. That doesn't make sense since that would hide field level security too.26 votes
In the past we had troubles deploying reports via CI, they were not showing/deploying, the workaround was to enable the filter to include all reports. This works to solve that, but now I am looking at including more into the repo and start using delete actions in the CI jobs as well. The downside is that because we have to have all reports in the filter, the CI job will delete reports created by users in non-private folders. A freedom we want to give certain users in Production.
What would be an epic enhancement (and solve this challenge) is if…25 votes
Explicitly set object-level permissions, even if these are omitted from XML provided by Salesforce API
Valerio recommended that I post this suggestion following a discussion on 29 August 2019.
1. Remove all object-level access for "Lead" from a custom profile in a source org
2. Deploy this profile to a target org
3. The profile in the target org will have access to the "Lead" object ENABLED, because this access is included in the Standard User profile (see document link above)
The workaround (deploying and then deploying again) is cumbersome and not always practical, e.g. if making automated, one-step deployments outside of Gearset. Failing to make a second deployment means that…24 votes
Allow user to directly create a change set without doing the comparison. If user has a list of items that needs to be migrated then allow the user to add items and skip comparison step.24 votes
As of now we are able to send only static text as a part of outgoing payload in CI Integration jobs. We want this data to be dynamic for each deployment.
For example: We need to send the information like (JIRA User Story number, GIT commit hashes and descriptions from the pull requests being merged, etc.)
This will allow us to publish information of successful deployments to external system.20 votes
After setting up a CI job from a Salesforce sandbox to a Bitbucket repo, it looks like the CI job always runs a commit, even if there are no actual changes. It would be great to not have this happen to avoid having many commits where there are no actual changes.20 votes
- Don't see your idea?