With Gearset's current the ability to associate a deployment with Jira tickets, and post updates as comments to the stages of deployments, the ability to choose the status (from what is defined in the status of the Jira Board), upon a SUCCESSFUL deployment, would be incredibly helpful in our environment plans for our projects.

By being able to select the status to update all tickets to from the Jira board, we could effectively manage our custom stages for different projects.

For CPQ Deployments add an "Upload from CSV" feature where a user could upload a file with specific External IDs across multiple objects to tell Gearset what to migrate in a single click.

For example, the user could list the Object API name in Column A of the sheet and the External ID in column B and then Gearset would parse this and create a Data Deployment based off of those records specifically. This would be incredibly useful for any CPQ deployment where you need to only deploy specific records not the entire object!

In the Validation deployment flow, there currently isn't a way to view test execution results if they aren't manually exported during the process. Having the ability to view the Validation Deployment report and details in this deployment flow is actually more valuable than the actual deployment report that is generated.
If we can't have that, it would be nice to be able to continue to export those test run results after deployment as part of the deployment details.

Being able to configure which problem analyser results to use in CI jobs.

For instance, we can’t deploy any changes to managed packages because the problem analyser will ignore them (even though we have components from a managed package that we can modify and deploy without issues), that would help to reduce our manual steps during deployments.

I have automated test jobs post about failed tests to our Slack. I want the posted Slack message to include a direct (though maybe shortened) link to the "Test run details" so that when we see Gearset telling us about some tests starting to fail I would be one click away from seeing a view of failed tests the message is talking about.

Next/bigger step would be a way to shape the Slack messages ourselves. The most basic templating setup where I could write my own Slack message with some placeholders like {{instance_name}} or {{failed_tests_link}}..

Please add the ability to use the "Compare and Deploy" for Attachments and Files. The ability to migrate PDFs, image files, word docs, and excel spreadsheets would be GREATLY appreciated! Thanks!

Allow complex filters and child relationships on filters for data loading. For example, filter the Account to only load if the Owner is an Active user in the system.

When comparing Custom Objects that contain the managed custom fields there is no way to suppress the managed custom fields. The fields would show up in the comparison results even without being requested. The problem analyzers then highlights and remove these managed custom fields.

This is cumbersome when repeated and makes finding genuine differences we care about more difficult.

From the problem analyzers, it sounds like Gearset is able to identify the managed custom fields. Therefore could there be an option under [Include managed package] in the Custom Filters that allows the suppression of known managed fields in comparison results?

Enterprise Users can only "Run Now" Jobs that they own. If the Source and Destination Org are shared, allow other enterprise users to run the job.

During a data deployment it should be possible to mask the data in specific fields. For example, if I were importing Account and Contact data from production into a sandbox I would want to be able to mask email address so that we can't erroneously send actual customers emails while we're testing

We have a bunch of CI Jobs, and it gets a bit difficult to identify whose job is owned by who just by looking at it.

Maybe make it similar to the Deployment History tab where I can sort out things by clicking the options above like "Owner" or "Name" and it'll organize it the way the Deployment History tab you guys have in place.

When configuring a CI job, we need an option to set a deployment to another sandboxe when the deployment or test classes run successfully in the current CI Job.
Ex: when a push to a branch on VCS triggers a CI job to deploy to a sandboxe like QA (with test classes run), we also have the possibility to set an auto deployment to staging sanboxe when the the job on QA passed successfully.

Include the name/id in the deployment detail page within Salesforce in the Gearset deployment report so we can trace and match those details to a deployment run in Gearset.

I would like a way for Gearset to create an immutable deployment package that can then be deployed to different orgs. This immutable package should contain a copy of the selected objects, list of unit tests to be executed and not allow variation in the deployment except selecting the target org. This would also save time by not requiring a new comparison to run for each target org.

Gearset does not allow comparisons or deployments of custom metadata on managed packages if the versions are different. We got ourselves in a situation where a package in the sandbox was a higher beta version that we couldn't upgrade to. This required us to do all the field deployments via changsets.

Adding a warning for deployments across managed package versions would be ideal as most changes one would deploy wouldn't necessarily cause any issues.

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.

ideally... gearset should not be hitting https://adlm.nielsen.com/bitbucket/rest/api/1.0/repos
first. It should hit https://adlm.nielsen.com/bitbucket/rest/api/1.0/projects to get a list of projects
then allow the end user to select the project
then https://adlm.nielsen.com/bitbucket/rest/api/1.0/projects/{projectKey}/repos to get a list of repos on the project the end user selects

1. Developer creates a pull request to a branch
2. CI job validates the pull request and notify in case of errors
3. Developer corrects errors - CI job again validates the pull request and this time it is fine
4.Release manager merges the pull request to the branch specific to an org and CI job deploys without error.