When setting up a deployment, it would be helpful to capture Deployment Results in a custom object in the running user's Salesforce org. Users would be able to specify a unique reference at the point of deployment, which would track through to the Salesforce org.

Information about the deployment would be captured in a Master record, with data about individual components existing in Detail records.

Org admins would then be free to leverage automation features to map the created records as they see fit.

As a consultancy that tracks our customer requirements in Salesforce, our use case would be that a 'requirement' record would become the source of truth for everything that happened with that requirement without manual intervention.

Problem analyzer is always trying to remove my picklist values from any RecordTypes on PersonAccount. I am forced to use a custom "Problem analyzer template" where "Remove picklists from record type" is disabled.

Suppose I have a field called pickme: Account.Pickme--pc | Contact.Pickme--c it shows up in the record type XML as Pickme--c, and it seems like gearset tries to find a picklist on account with that exact API name, which will of course fail. My ask is that rather than raising an error at this point, GS should repeat this check on the contact object where it would find a match.

It would be great if we can have the option to set and make use of 'deployment rules':

1 - receive an alert/warning message (in gearset/via email) right before deploying to a selected target environment, for instance - a production environment if certain pre-defined metadata types are included in the deployment.

use cases: a reminder to run all test when deleting metadata, a reminder to activate a flow on target environment after deployment.

2 - block a deployment in the following case scenarions:

a - if the deployment of certain pre-defined metadata types happens within a pre-defined timeframe.

use case: deployment of sharing rules during business hours

b - if certain pre-defined metadata types are not deployed by a certain role (e.g. team lead/owner).

use case: only team lead can deploy metadata for critical components (e.g. account and case triggers).

Criterias that may be used:

• metadata types included in the package
• keywords
• users
• date/time range
• target environment

I would like all of my 'Admin' users (or specify which users in my org) can have access to run monitoring jobs I've set up.

The scenario is that we're a small team, so I want to set up all of our monitoring jobs, but if an issue occurs while I'm OOO any of my other team members could run the 'Take Snapshot' function to determine which changes occurred since the last monitor job ran and roll the changes back.

Currently users can edit/delete monitor jobs of other users and if provided 'Deployment' access can roll the changes back, but they're not able to run the snapshot functionality.

At the moment when you select a Jira ticket at the point of commiting to a branch, you are able to track that actionback into Jira.

However when a PR is opened from that feature branch to the next environment branch (in the Pipelines UI specifically) the Jira ticket association is lost, and has to be reattached manually.

Workaround:

1. Put the ticket ID in the branch name, i.e. name your branch "feature/AL-99- new-flow"
2. Use the drop down menu provided in the Pipelines UI to re select the Jira ticket
3. Open the PR from the Commit successful screen and tick the box to include Jira ticket links

Please could the Jira ticket be "remembered" or the ticket ID automatically added to the PR description, so that it does not need to be reattached, saving the user a couple of clicks.

Expose the underlying JSON/XML for Custom Filters so that we can export it, modify it in a text editor either by hand or with python scripts, then load it back into the custom filter.

For example I have my main CI filter with 50ish metadata types, and every other filter is a subset which I establish by cloning the "master" filter and deselecting metadata types. Whenever I make a change to the master filter I am forced to nuke all the the "detail" filters and recreate them off the master using the above approach.

So many clicks. My preference would be to manage all this as text-based files.

https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/38358922-inline-editing-of-metadata

The idea above was "closed" due to Environment Variables.

That feature is too fiddley for our use case as the change that needs to be performed is not consistent. Furthermore, that feature does not help with handling merges.

Gearset has some merging capabilities, but it only allows to select one file or another, instead of merging changes from both files.

I'm aware it is possible to perform merges from source control, though it would be easier to train our team if they did not have to learn another technology. Furthermore, it leaves the process to more faults as the user can easily finish the pull request inside the source control causing some process to not be executed properly or consistently (e.g. branches not being closed or new pull requests opened).

A non merge/pipeline example, just comparison and deployment. I may have code on my sandbox that is for testing purposes, or is still in development, and it is to not be propagated to other sandboxes.

I'm not expecting anything complicated, I would be happy even if it was a text editor, though hopefully it has indentation capabilities.