It will be helpful if we know who/when a filter is changed. And it would be great if we could lock the filters as an owner.1 vote
In rarer situations where I need to make some manual adjustments to the metadata XML for a deployment, I'd like to be able to download the metadata to adjust it. Today you need to go through a compare, and at the end, you can download the package, but this can be problematic, since you have to choose the target org, there need to be differences, etc.
Instead, it would be useful to just choose the source org, select the metadata items, and save the package, without a target org needed.1 vote
Similar to "Pending Deployments" It would be nice to see pending validations. We have several users in gearset, so if we are trying to validate something while someone has already initiated a validation, we receive the error that set up has been locked. So prior to validating a package, it would be great to check if anyone is in the process.1 vote
Right now, the only way to edit a group's membership is via the API (users or groups only) or the UI (additionally allows roles, roles and internal subordinates, etc.). Please allow the editing of group membership of public groups.1 vote
We use Clone from Deployment History quite often. A typical use case would be:
Deploy from feat org F to branch
Do PR & merge to /master
.. CI runs
Upon successful CI
Clone deployment with source = master and target = QA org
Upon successful UAT
Clone deployment with source = master and target = PROD org
Rather than having to re-enter on the Clone dialog the source and targets, since they are always the same, it would be nice to "favorite" sources and targets (assigning a favorite name) and then reusing those favorite names on the Clone dialog1 vote
When you open a Draft Deployment it would be great to see its name on the deployment page as well as its refresh date. I understand that when you open a draft deployment you're seeing a snapshot from when it was created or refreshed.1 vote
Currently, when you rename existing picklist values in the source org (including renaming the API name of that value), Gearset will deploy this to the target org as a new picklist value and deactivate the old value. This means we have to manually delete the value in the target org and specify which value to use to replace on existing records.
It would be great if Gearset could give the option to map a picklist value in the source to a picklist value in the target and allow a rename of the value in the target.1 vote
it would be good if we can send email notification to Users whenever we successfully deploy components to specific Org regardless of CI job.0 votes
- Don't see your idea?