1354 results found

1. Enable multiple orgs to act as build agents for single pipeline step

   Occasionally our queue is backed up waiting for dozens of PR's to validate, this happens because a single org can only validate one PR at a time. It would be helpful for a solution that allows us to attach multiple orgs (sandboxes or scratch orgs) to a pipeline step such that multiple PR's could be validated in parallel. Then when a PR is deployed it could easily be deployed to all of the attached orgs.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployment automation  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Solution for enabling parallel builds validations, i.e. multiple build agents

   Occasionally we have a backup in our queue PR validations where dozens of tickets all have to individually wait for there spot in line to validate. It would be great if we could spin up multiple orgs (sandboxes or scratch orgs) and attach them to a single pipeline element such that each org could help load-level the validation queue.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployment automation  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Preserve Precision Selections through Fetching the Latest

   You're precision selections feature is absolutely amazing! Every time I use your tool it just gets better and better and this feature has me hooked. It's been huge with lightning web pages which often have multiple changes in UAT and need to be separated for deployment.

   We prep deployments before sending to UAT. Occassionally, there has been a big delay since the package was originally validated. If I need to go back to the original draft deployment and refresh the selected items to ensure I'm not overwriting something else that went out, the precision selections are cleared.

   1. There is a message that the precision selection is cleared - Thank You! It's helpful to know that happened.
   2. Once they get cleared, it's hard to remember which components had precision selection
   3. Once they get cleared, it's hard to remember which precision selections we're in the prior comparison for each component

   In a perfect world gearset could do something like a git rebase and attempt to apply the same selections with the current comparison. And when that isn't possible (as git rebase often is) to provide some route to have the original selections available for reference so I can confidently choose the correction selections with the current comparison.

   As an example, I have a lightning web page where I added a button to the highlights section and removed a component from the sidebar. After the refresh it could just show a brief diff of what was previously in there, auto-select it if the system can reason what it is, and if not flag it with context (e.g. removed component x from sidebar, not automatically mergeable, reselect manually).

   And short term, just some way to keep the components that were selected visible easily with a message that they previously had precisions selections would be a huge help.

   Thanks for the great work. Keep it up!

   ps - The fetch the latest is also one of my favorites. It's gotten so much faster to iterate on preparing deployments now that I can really precisely refresh just the metadata I know was changed!

   You're precision selections feature is absolutely amazing! Every time I use your tool it just gets better and better and this feature has me hooked. It's been huge with lightning web pages which often have multiple changes in UAT and need to be separated for deployment.

   We prep deployments before sending to UAT. Occassionally, there has been a big delay since the package was originally validated. If I need to go back to the original draft deployment and refresh the selected items to ensure I'm not overwriting something else that went out, the precision selections are cleared.

   1. There is a… more
   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. allow us to automate the PR Syncs after a shedule deployment occurs

   due to drift occurring because of the environments being out of sync after a deployment occurs I would love the capability to scheduel an automated PR sync after a successful scheduled release deployment occurs. like a checkmark box on a per sscheduled deployment basis.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Data deployment  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Customizable Metadata Deployment Order - Destructive change and reference changes

   We should be able to define the order of metadata deployments. For example, when deleting a custom field and updating its references, we currently need two separate deployments: one for modifying references and another for field deletion. Allowing us to set the deployment order—modified references first, then field deletion—would enable this in a single deployment, streamlining the process.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployment automation  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. Make components searchable across features in the pipeline

   If I know the name of a component, Can you give me a way of searching through the pipeline to see what features it resides in, where they are and when it was deployed please

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Comparisons and difference visualization  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. Deployment Failures in Pipeline

   The flow of a pipeline promotion is as such:

   1. Validate deployment to org
   2. (on success) Merge PR into base branch AND move PR to "Recent Promotion History" tab
   3. Deploy to org

   IF the deployment fails at that point, or is partially successful it would be great to denote that somewhere within the CI job within the pipeline. This would give the devs.admins more visibility into the true state of their features. Maybe we don't even move to the next environment until after a successful deployment.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Automatically Backfill Dev Environments with Pull Request When Changes Are Promoted Downstream

   Description:
   Currently, Gearset’s pipeline tool does a great job of back-propagating changes between static environments when a change is made further down the pipeline. However, this behavior does not extend to developer environments, even if the change originated from a feature branch tied to that dev environment.

   Problem:
   If a developer starts work on a branch in their dev environment, and then that branch is promoted down the pipeline (e.g., through UAT, Staging, etc.), and changes are made to the branch further down (e.g., hotfixes, last-minute edits), those updates do not automatically get proposed back to the original dev environment.

   This leads to:
   - Dev environments drifting out of sync with the branch they were created from.
   - Increased manual effort to merge updates back into a dev environment.
   - A risk of bugs or inconsistencies when developers continue work unaware of downstream updates.

   Proposed Solution:
   When changes are made to a branch in a static environment further down the pipeline, and that branch originated from a dev environment, automatically create a pull request to update the dev environment’s branch with those changes.

   This would:
   - Keep the dev environment aligned with the true state of the branch.
   - Reduce manual syncing and the risk of drift.
   - Improve collaboration and awareness for developers working on long-lived branches.

   Description:
   Currently, Gearset’s pipeline tool does a great job of back-propagating changes between static environments when a change is made further down the pipeline. However, this behavior does not extend to developer environments, even if the change originated from a feature branch tied to that dev environment.

   Problem:
   If a developer starts work on a branch in their dev environment, and then that branch is promoted down the pipeline (e.g., through UAT, Staging, etc.), and changes are made to the branch further down (e.g., hotfixes, last-minute edits), those updates do not automatically get proposed back to the original dev environment.

   … more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Add Monday.com as a source for User Stories

   Add Monday.com as a source for user story integration

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Enhancement Proposal: De-merge Option for Gearset Branch Management

    Currently, Gearset provides a helpful feature to merge branches, which is ideal for creating a Release branch that bundles all related components. However, it would be a valuable enhancement to introduce a de-merge or selective unmerge capability. This would allow teams to easily remove specific feature branches from a Release branch particularly useful in scenarios where some stories are pending approval or need to be excluded from the release at the last minute.
    Such a feature would improve flexibility during final release preparation and reduce the need for manual branch adjustments or rework.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Deploy CustomLabel by label separately

    The automated deploy (CI) filter does not have the resources to deploy isolated CustomLabels, so that specific labels can be included or excluded.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Deployment automation  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. load more items

    Please stop using "Load more items..." as the way to load more table items. It's very annoying to have to say show me the last 30 days but then click the button 20 times to get there.

    I'm referring to the Promotion history page but anywhere this concept is used should be ripped out.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Please add support for decomposeCustomLabelsBeta

    Salesforce added the option to configure multiple features in the DX Project Configuration file. One of the is breaking down the big CustomLabels file into individual files where we no longer need to deploy the whole file but just a file (label) that has changes in. Please see SFDX Documentation here - https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_config.htm

    11 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  New feature  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. Stop Off-setting Partial Selections when a Package is 'Fetched' for the Latest

    Hi,

    Our team creates individual draft deployment packages and then we consolidate it into one package and fetch for the latest before validating. In some of our individual draft deployment packages we are selecting partial changes to a page layout or a lightning record page but it is off-setting this partial change and we are given the prompt: 'Precision selections have been reset for these items'. Is there a way we can fetch for the latest without off-setting these partial changes?

    Thanks!

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Problem analysis and deployment failures  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. View webhook pipeline settings and error history even when promoting

    When any pipeline is promoting most of the options in the pipeline settings menu are disabled, e.g. 'View Webhook Errors'.

    We want to be able to access these features, as we might need to reference a webhook error, and not have to wait until the pipeline is finished promoting. Our team is promoting at least one feature to one pipeline most of the day so we have to wait until after business hours to reliably access this information.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Enable use of multiple parent filters under 'Filter using parent object' in data deploys

    When the “Only deploy (object name) records that are children of the (dropdown of selectable objects) records that are being deployed.” checkbox is selected on the Account object settings screen of a data deploy, only one parent record can be selected. The ability to filter by multiple fields would be useful in my org.
    Use case: we have a custom object Beneficiaryc with lookups to 2 different objects: Asset_Groupc and FinancialAccountc. AssetGroupc and Financial_Accountc are both children of the Account object, so I’m able in one deploy to include Account records with all child AssetGroupc and FinancialAccountc records, but I have to choose between including all Beneficiaryc records that are children of deployed FinancialAccountc records or AssetGroupc records; I can’t include both. My current workaround is to do a second deploy just of Beneficiaryc records, but if the Filter using parent object feature had the flexibility of the standard Configure filter function with the ability to add fields and logic, we would be able to accomplish this in a single deploy.

    When the “Only deploy (object name) records that are children of the (dropdown of selectable objects) records that are being deployed.” checkbox is selected on the Account object settings screen of a data deploy, only one parent record can be selected. The ability to filter by multiple fields would be useful in my org.
    Use case: we have a custom object Beneficiaryc with lookups to 2 different objects: Asset_Groupc and FinancialAccountc. AssetGroupc and Financial_Accountc are both children of the Account object, so I’m able in one deploy to include Account records with all… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Data deployment  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. I would like the ability to auto promote updates to inflight feature branches

    When using feature branch promotion in pipelines, I often find myself in a scenario where I’ve pulled a new feature through the pipeline to one of my static environments. I then test it, discover something that needs to be changed, make the change in the dev environment, and pull that change through the pipeline again so it reaches the same static environment for retesting.

    I would like functionality that enables me to release a new change to that branch from dev and have it automatically promote through all static environments, stopping at the current one where the original pull request resides. This way I don't have to keep actively managing the pipeline and clicking promote every time it gets to a new static environment.

    When using feature branch promotion in pipelines, I often find myself in a scenario where I’ve pulled a new feature through the pipeline to one of my static environments. I then test it, discover something that needs to be changed, make the change in the dev environment, and pull that change through the pipeline again so it reaches the same static environment for retesting.

    I would like functionality that enables me to release a new change to that branch from dev and have it automatically promote through all static environments, stopping at the current one where the original pull request… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. add preview of archived files and let admin choose fields to show on the related list in Archive Viewer

    Please improve Archive Viewer with a preview of the files Archived, like the current document viewer on SF and consider to add more functionalities on the related list shown on Archive Viewer, like choosing fields to show and search bar incorporated.
    These functionalities are already available with other Archive apps connected to SF.
    Let users select the record to restore directly from the related list in Salesforce.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. Using Back Promotion for single Environments only and selective PR's only

    We normally update our developer orgs with the "update sync" function after the PROD release. However, sometimes we have changes that are build on top of each other but developed by multiple devs and therefore orgs.

    In that cases, it would be nice to turn on "back promotion" but only for certain environments where it is needed and not globaly. In addition, being able to selectively create back promotions for PRs would be nice as well.

    At the moment, if the feature is activated, Gearset is creating a back promotion for every PR, regardless if it is needed or not. Which means after the release, you have to delete the ones that where not needed manually.

    Best would be to select a checkbox during "push" creation and also a option to create a back promotion after it already has been pushed.

    We normally update our developer orgs with the "update sync" function after the PROD release. However, sometimes we have changes that are build on top of each other but developed by multiple devs and therefore orgs.

    In that cases, it would be nice to turn on "back promotion" but only for certain environments where it is needed and not globaly. In addition, being able to selectively create back promotions for PRs would be nice as well.

    At the moment, if the feature is activated, Gearset is creating a back promotion for every PR, regardless if it is needed or not.… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Select All PRs for promotion

    When promoting PRs from one environment to another in the pipeline, it would be useful to have a "Select All" option

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating