1382 results found

1. Ability to "Hide" Sandbox Groups on Pipeline Page

   In the Pipelines page, it would be very helpful if we had the ability to "hide" entire sandbox groups from view. This would make it much easier to quickly find and focus on the environments that are relevant to the logged-in user.

   Ideally, this "hidden group" setting would persist across logins and page refreshes, similar to how the "collapse group" feature currently works.

   I'm sure an "unhide groups" feature will be needed with this as well, in case a previously hidden group becomes relevant again.

   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

2. Allow Archive Notifications for both successful and failed runs

   Currently, when an archiving policy runs, you can send out a notification if a run has been successful or a notification when a run has failed. I cannot see a way to have both notification types as I would like to see at a glance how many records have been archived in each run, but I also need to know when it fails with permission issues after deployments or major releases. I do not go into the Archive section every day.

   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  ·  Monitoring and reporting  ·  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. Provide a Model Context Protocol (MCP) for Gearset

   It would be really helpful if there were a Model Context Protocol (MCP) server for Gearset. As companies are adopting AI LLM tools as part of their day-to-day work, integrations with tools like Gearset become a necessity and MCPs are becoming more and more available, even Salesforce has support now (https://developer.salesforce.com/blogs/2025/06/introducing-mcp-support-across-salesforce).

   As an example, we use Claude Deskop connected with an Azure DevOps MCP (https://github.com/microsoft/azure-devops-mcp) to connect to ADO. Claude helps assess priorities, organize releases, check for duplicate issues, and even identify issues that have fallen through the cracks.

   Expanding on that, it would be really helpful to have a Gearset MCP which Claude could connect to Gearset and look at things like deployment history, draft deployments., PRs. automation pipeline, and be able to answer questions about the status on various issues/bugs, etc, which exist on tools like ADO / JIRA, and help assess things like:
   When an issue was deployed, and to which environment.
   Or if a draft deployment includes all the metatdata/components needed to resolve the user story in ADO/JIRA. There are a lot of options!

   It would be really helpful if there were a Model Context Protocol (MCP) server for Gearset. As companies are adopting AI LLM tools as part of their day-to-day work, integrations with tools like Gearset become a necessity and MCPs are becoming more and more available, even Salesforce has support now (https://developer.salesforce.com/blogs/2025/06/introducing-mcp-support-across-salesforce).

   As an example, we use Claude Deskop connected with an Azure DevOps MCP (https://github.com/microsoft/azure-devops-mcp) to connect to ADO. Claude helps assess priorities, organize releases, check for duplicate issues, and even identify issues that have fallen through the cracks.

   Expanding on that, it would be really… 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  ·  Integrations and connections (Jira, source control, DX etc.)  ·  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. add support for lightning types (LightningTypeBundle)

   Add support for lightning types (LightningTypeBundle)

   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

5. Display the developer who opened the PR throughout the entire pipeline flow.

   As a Release Manager, I have difficulties identifying the developer responsible for the PR.

   The developer's name only appears when they open the PR at the beginning of the process, and in the following stages, it shows the system user's name from git that Gearset uses to open the PRs up to production.

   Since I need to easily know who opened the PR during the release creation, I have to open the feature card to find the developer. ...

   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  ·  Team and account management  ·  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

6. View Deployment Summary from Pipelines

   My team develops in siloed dev orgs. Once a feature is complete, we create a PR against an integration environment.

   This triggers a test suite run in the target org and a peer code review. This process works well for Apex. However, admins on our team build automations in Flow, which are nearly impossible to review in GitHub due to the complexity of the XML.

   To address this, we’ve been using Gearset’s Flow Navigator for Flow code reviews. Previously, it only took a couple of clicks to reach the Deployment Summary screen, and the Flow visualization made reviews much easier.

   After a recent UI update, accessing Flow visualizations now requires a longer, more manual click path:

   1. Click the environment and note the PR# for the Flow(s) to review.
   2. Go to CI Jobs.
   3. Expand the target environment.
   4. Locate the PR by number.
   5. Click Validation runs.
   6. Click View Summary.
   7. Click Back to results.

   That’s 6–7 clicks plus manual PR lookup. Much less efficient than before.

   Since Flows are a common part of development and Flow Navigator is a powerful review tool, it would make sense to add functionality in the Pipelines Open PR screen to quickly view branch contents and Flow visualizations directly in Gearset.

   My team develops in siloed dev orgs. Once a feature is complete, we create a PR against an integration environment.

   This triggers a test suite run in the target org and a peer code review. This process works well for Apex. However, admins on our team build automations in Flow, which are nearly impossible to review in GitHub due to the complexity of the XML.

   To address this, we’ve been using Gearset’s Flow Navigator for Flow code reviews. Previously, it only took a couple of clicks to reach the Deployment Summary screen, and the Flow visualization made reviews much easier.

   … more

   4 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

7. 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

8. 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

9. 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

10. 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

11. Using GitHub Apps to Replace Service Account for Team Shared Connection

    Problem Statement / Current Situation:

    For enterprise security compliance, organizations are moving to a model where all third-party integrations must use pure application-based identities (like GitHub Apps) instead of user-based accounts.

    Currently, Gearset's CI/CD jobs require a "Team Shared Connection," (https://docs.gearset.com/en/articles/8455568-team-shared-source-control-connections) which uses a combination of a GitHub App for authorization and a separate GitHub "service account" user for commit attribution. While this is a functional workaround, it still forces us to create, manage, and secure a user entity in GitHub. This goes against modern security principles that aim to eliminate the management of all user credentials, even for service accounts.

    Proposed Solution:

    We propose that Gearset enhance its GitHub integration to allow a GitHub App to be used as a complete, standalone identity for CI/CD operations.

    This would mean that when a CI job runs a merge, the author of the merge commit would be the GitHub App itself, not a separate service account user. This is an emerging best practice in the industry, as a GitHub App can have its own identity and be an actor within the system. As security expert Josh-ops notes in his detailed article on the subject, this provides a more secure and streamlined approach by "moving the identity from a user to the application itself."

    Problem Statement / Current Situation:

    For enterprise security compliance, organizations are moving to a model where all third-party integrations must use pure application-based identities (like GitHub Apps) instead of user-based accounts.

    Currently, Gearset's CI/CD jobs require a "Team Shared Connection," (https://docs.gearset.com/en/articles/8455568-team-shared-source-control-connections) which uses a combination of a GitHub App for authorization and a separate GitHub "service account" user for commit attribution. While this is a functional workaround, it still forces us to create, manage, and secure a user entity in GitHub. This goes against modern security principles that aim to eliminate the management of all user credentials, even… more

    3 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

    1 comment  ·  Integrations and connections (Jira, source control, DX etc.)  ·  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. Enable Excel export of org differences—profiles, permission sets, and objects—in the same side-by-side format with change indicators

    I compared two profiles from different orgs—specifically, the old and new environments of the same company—to identify any differences and present them to the client for review and approval of necessary changes in the new org. However, I was unable to export the comparison results into Excel. It would be extremely helpful to have the ability to export the comparison data in the same structured and visual format as shown in the Gearset comparison window, making it easier to review and share with stakeholders.

    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  ·  Comparisons and difference visualization  ·  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. 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

14. 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

15. Provide a visual indicator on upstream systems when out of sync with master

    Often times we see drift items added to PR's in our upstream systems. It would be nice to have an indicator that shows if a static branch is out of sync with master.

    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  ·  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

16. Automate upstream branch syncing

    After merging/deploying to prod allow auto-creation of sync PR's to upstream branches/orgs (QA, UAT, Staging, etc...). If the sync PR's could be promoted automatically that would be amazing.

    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  ·  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

17. 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

18. 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

19. Add spell checker to CI/CD pipeline

    Spell checker helps maintain a high standard of accuracy, ensuring your content is reviewed in initial PR's itself. Just like how we use Clayton code feedback.

    If typos is in customer facing texts in UI (which is can be a big problem in public facing application where large no of users visits.)

    It would be good if spell checker can be added as a policy inside Clayton. So that we can find and fix issues easily.

    Advantages
    * We can also prevent potential PROD P1 errors.
    * Enhanced Code Quality
    * Improved Deployment Efficiency
    * Reduced Technical Debt

    9 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

    1 comment  ·  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

20. 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