On the “My Connections” page, I'd love to see an option to add a folder (and sub-folders).

Currently, there are options for "Developer orgs", "Sandbox orgs", "Production orgs", and "Scratch orgs".

If you are running more than one entity, having the sandboxes related to a single entity inside of a folder would be more user-friendly than having multiple dev/sandbox orgs inside the same folder.

For example, if I'm managing deployments for "ABC Company", "XYZ Company", and "LMNOP Company", and each has multiple sandboxes, it would be really convenient to be able to separate out their various sandboxes more effectively, into their own company folders, rather than all grouped inside of the same "Sandbox orgs" folder.

Custom user folders:

-  External Clients

    -  ABC Company

        -  Sandboxes

        -  Production org

    -  XYZ Company

        -  Sandboxes

        -  Training org

        -  Production org

Currently, profiles in source control are stored with everything as it's all stored in a single file (apex class permissions, layout assignments, etc). This is done by Salesforce.

When using the new "delta deploy" or any comparison that doesn't include every possible dependent component (ex. apex, layouts, etc) - you see many "new" or "deleted" items related to the fact that source control returns everything within the profile whereas Salesforce only returns specific permissions based on the retrieved components.

It'd be great if Gearset could replicate this behavior with source control to match Salesforce's behavior, where it'll obviously have to the pull the profile with everything included, but then could do some extra filtering so the comparison or CI job only looks at the relevant sub-component pieces within the file.

This would ensure a more expected diff visualization or delta deploy behavior.

Would like the ability to delete multiple history items at once. The current process of clicking delete and then clicking the confirmation is cumbersome and time consuming when we have multiple users and multiple environments kicking off many CI validations through the day. Failure to clean up the Validation history, especially, eventually brings Gearset CI viewing to a crawl. Having the ability to delete multiple at once and/or a the ability to add a retention period for history would be ideal. Validation history is the most important because you can't filter by time period like you can when you go to Deployment history and it seems validation history loads behind the scenes even thought the sections are collapsed..

In Salesforce, if you add an image to a PathAssistant, it hard codes the sandbox URL in the metadata. This causes failures when you then try to deploy that item to the next environment. My idea is that a feature is added that would allow some sort of find/replace logic that's applied prior to the CI compare. Something like:
File: Enter the name of the package file
Search Text: The text and/or regex string to search the file for
Replacement Text: The text to replace found the text with

In this way, it would modify the source file prior to the compare and then use the modified version if there are other differences between the two files.

The workaround is to either remove the file from the pacakge.xml or the meta-data filter so it quits breaking the validation, but this only works if you never have to change the code.

We have a feature branch we create a PR 1 to SIT -> we merge the branch -> deploys to SIT -> we delete the branch

We have a feature branch we create a PR 2 to SIT -> we merge the branch -> deploys to SIT -> we delete the branch

now both PRs are in SIT branch

we make a PR from SIT to UAT -> Both PR's are validated against UAT -> if all is good both PR's get deployed to UAT

but then Monday comes and business wants JUST PR1 to be deployed to production

so we make a PR from UAT to the main branch which is merged -> then we trigger the manual comparison and go through the PR files list to add them manually

instead, if we could have just cloned the deployment triggered by the PR1 and pointed from the main branch to production will be much quicker and easier

PR2 is merged to the main branch but it's not really ready for production

so when the time comes for PR2 we can refer to that very first deployment to clone it

in a perfect world, all PRs go at the same time but in most cases, this is not the reality