1339 results found

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

   6 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

2. Auto merge of PRs

   Once the validation process is successfully completed for the respective PR, it would be very helpful to have an option for automatic merge and deployment. This would streamline the release process and reduce manual steps.

   Additionally, it would be great if we could have control at the org level to enable or disable auto merge functionality. This way, teams can decide whether they want to use auto merge based on their workflow preferences or organizational policies.

   Thank you for considering these enhancements!

   7 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

3. Darkmode option

   It would be really helpful having a dark mode of gearset UI. A big number of devs prefer dark mode over bright mode. Since gearset is a tool mainly used by devs, would be good to give to devs the option to customize their UI.

   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

4. Ability to Select and Merge Specific Changes in Lightning Components and Flows

   We are using Gearset to compare and merge changes in Lightning and Aura components, as well as Salesforce Flows. While the tool works well overall, we’ve noticed that it currently lacks the ability to select and move specific changes during a merge. Instead, it requires replacing the entire file, which isn’t ideal in many cases.

   It would be extremely helpful if Gearset could allow selective merging of specific lines or sections—similar to how it works for Apex classes. This feature would greatly improve control and efficiency when working with Flows and Lightning components.

   Thanks for considering this enhancement!

   6 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

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

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

7. Delay Jira status updates until after post-deployment steps are completed

   Currently, when using the Jira integration with Gearset pipelines, status updates happen immediately after the initial deployment completes, but before any post-deployment steps are executed.

   We need the ability to configure Jira status updates to occur only after ALL post-deployment steps are successfully completed. This would ensure tickets only show as ready for validation when they're truly ready to be tested.

   This is important for teams that have mandatory post-deployment steps (like data imports, configuration changes, or additional verifications) that must be completed before a story is actually ready for testing. The current behavior can lead to confusion when testers see a 'ready for testing' status but the application isn't fully ready yet.

   Currently, when using the Jira integration with Gearset pipelines, status updates happen immediately after the initial deployment completes, but before any post-deployment steps are executed.

   We need the ability to configure Jira status updates to occur only after ALL post-deployment steps are successfully completed. This would ensure tickets only show as ready for validation when they're truly ready to be tested.

   This is important for teams that have mandatory post-deployment steps (like data imports, configuration changes, or additional verifications) that must be completed before a story is actually ready for testing. The current behavior can lead to confusion when testers… more

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

8. Add a feature to ignore queue members when deploying queues

   When deploying Queues with Gearset the members section is automatically included and the member list is deployed to the target org. Gearset has a suggested fix to sync the queue members with the target environment but it doesn't always work.

   Salesforce supports deploying queues with an empty list of users as queue members are more like data than metadata I suggest a feature toggle in Gearset where the users section of the queue is ignored for deployments to preserve the user list in the destination org.
   Our company and many others probably maintain the queue users directly in production as it's done with public group membership.

   Here is an excerpt of the xml and what to remove to preserve the queue members in the target org.

   <?xml version="1.0" encoding="UTF-8"?>
   <Queue xmlns="http://soap.sforce.com/2006/04/metadata">
   <doesSendEmailToMembers>false</doesSendEmailToMembers>
   <name>QueueNameTest</name>
   <!-- Remove from here
   <queueMembers>
   <users>
   <user>bla@blabla.com</user>
   </users>
   </queueMembers>
   Remove to here-->
   <queueRoutingConfig>Test</queueRoutingConfig>
   <queueSobject>
   <sobjectType>Case</sobjectType>
   </queueSobject>
   <queueSobject>
   <sobjectType>LiveChatTranscript</sobjectType>
   </queueSobject>
   </Queue>

   When deploying Queues with Gearset the members section is automatically included and the member list is deployed to the target org. Gearset has a suggested fix to sync the queue members with the target environment but it doesn't always work.

   Salesforce supports deploying queues with an empty list of users as queue members are more like data than metadata I suggest a feature toggle in Gearset where the users section of the queue is ignored for deployments to preserve the user list in the destination org.
   Our company and many others probably maintain the queue users directly in production as… 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

9. add the ability to set a Profile Picture

   Honestly I'm actually surprised it's not possible to set an avatar at the moment, it seems a pretty basic feature in today's online world!

   As a neurodivergent team, we want to increase accessibility by being able to distinguish our team members within the platform faster and more easily, so that we can increase our productivity.

   It's simply easier to recognise my user in GS if it's "the one with the funny cat" instead of just my initials. Similarly, since we have team members with the same initials that also makes it harder to distinguish them in GearSet since their profile icon is the same.

   Honestly I'm actually surprised it's not possible to set an avatar at the moment, it seems a pretty basic feature in today's online world!

   As a neurodivergent team, we want to increase accessibility by being able to distinguish our team members within the platform faster and more easily, so that we can increase our productivity.

   It's simply easier to recognise my user in GS if it's "the one with the funny cat" instead of just my initials. Similarly, since we have team members with the same initials that also makes it harder to distinguish them in GearSet since their profile… more

   8 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  ·  Team and account management  ·  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. Pick up test classes to run from the apex class

    Add a variable in apex classes where we can specify which test classes to run.

    Recently you added the ability to specify the test classes to run on a pull request, which is great!

    I know <ApexClassName>Test are automatically picked up by GS, but would be great if we could specify with
    @TestClasses('CaseTestSuite,LeadTestSuite') or similar in the actual Apex Class and Gearset would automatically pick it up and add those test classes to the pull requests .

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

11. Show doesRequireRecordChangedToMeetCriteria on Flow Navigator

    The doesRequireRecordChangedToMeetCriteria toggle on flow Decisions doesn't show on Flow Navigator, making it harder to check for issues on builds when using the comparison tool.

    doesRequireRecordChangedToMeetCriteria should show in the flow navigator, same as the rest of the decision configuration.

    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

    5 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

12. Allow multiple team members to be assigned to a single sandbox on the pipeline view

    Currently a single team shared sandbox can have multiple users with delegated access. However, only one of the users can view the sandbox in a pipeline view. In order to allow multiple people to see the sandbox -

    Current solutions:
    - Add the same sandbox multiple times and assign each to the required team members
    - Or, allow all team members to see all sandboxes

    Suggested solution:
    - Allow multiple team members to be selected via the "Assign sandbox to team member" function.

    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

    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

13. Remove "No Difference" items when commenting on jira tickets

    when i connect a jira ticket to a commit, I like the way gearset posts a comment on the jira ticket listing the changed items. what I dont like is the long list of "no difference" items posted on the ticket. It makes the ticket comments super long and annoying to scroll through. can gearset update this to only post the difference metadatas, or at least give us the option to include or exclude

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

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

16. Enable AccountContactRelation standard object as part of data deploy

    After chatting with support, it seems to be impossible to deploy an AccountContactRelation record when IsDirect = TRUE, meaning the AccountContactRelation is between a Contact and its primary Account.

    When I try deploying an Account record, Contact record and the AccountContactRelation record that joins them as top-level objects in the same deployment, I receive the error "INVALIDCROSSREFERENCE_KEY:You can't associate a private contact with an account.:ContactId --", presumably because in the order of operations, the Contact hasn't been updated with the Account lookup yet.

    When I try splitting this into 2 deploys, deploying the AccountContactRelation alone as part of a second deployment to an org where the Account and Contact records already exist, I receive the "DUPLICATE_VALUE:This contact already has a relationship with this account.:ContactId" error, because the AccountContactRelation was automatically created due to the Account being primary for the Contact.

    My organization uses multiple business-critical fields on the AccountContactRelation object, and we cannot find a way to populate them via data deploy, and have thus far resorted to manual population or separate dataloads.

    After chatting with support, it seems to be impossible to deploy an AccountContactRelation record when IsDirect = TRUE, meaning the AccountContactRelation is between a Contact and its primary Account.

    When I try deploying an Account record, Contact record and the AccountContactRelation record that joins them as top-level objects in the same deployment, I receive the error "INVALIDCROSSREFERENCE_KEY:You can't associate a private contact with an account.:ContactId --", presumably because in the order of operations, the Contact hasn't been updated with the Account lookup yet.

    When I try splitting this into 2 deploys, deploying the AccountContactRelation alone as part of… 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

    1 comment  ·  Bug  ·  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. Changing API Version should make it obvious to save filter before CI Job can be saved

    It's a usability bug, I think.
    When you change the API version in a CI Job, the button to save CI Job greys out but has a spinning dial of 'Something happening'. Actually the system is doing nothing, it is waiting for the filter to be saved (even if the filter wasn't saved before) but this is completely unclear.
    Changes then
    1. auto-save filter or bring up the 'save filter' modal
    2. Show a toast message saying "save filter"
    3. Button should grey out with hover text of "save filter", no spinner

    I waited longer than I care to admit, hoping the button would un-grey itself

    It's a usability bug, I think.
    When you change the API version in a CI Job, the button to save CI Job greys out but has a spinning dial of 'Something happening'. Actually the system is doing nothing, it is waiting for the filter to be saved (even if the filter wasn't saved before) but this is completely unclear.
    Changes then
    1. auto-save filter or bring up the 'save filter' modal
    2. Show a toast message saying "save filter"
    3. Button should grey out with hover text of "save filter", no spinner

    I waited longer than I care to admit,… 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

    1 comment  ·  Bug  ·  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. Update Test naming convention matching to work with implementation classes

    We are using fflib and the AEP enterprise design pattern. As part of this design pattern we have interfaces and implementations for our Service layer classes. E.g. we will have something like ILumpSumService and LumpSumServiceImpl. When we create a test class it would be something like LumpSumServiceTest. So it would be great if the logic could be updated to match use cases where you have an implementation class like that. Also, I think any net new test classes added should be executed no matter what

    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  ·  Testing  ·  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 an integration for Google Chat that includes an integration for Change Monitoring and Unit Testing.

    Recently, it seems that Google Chat has reached some feature parity with Slack in that it has a defined integration avenue for adding notifications to Google Chat. I have found that I can set up a custom webhook to Google Chat for the CI jobs, but webhooks are not available on the other 2 features I am looking for notifications from.

    I would either like to have:
    a.) An integration for Google Chat with an app on the Google Chat side that we would add for the connection to our Gearset
    b.) Webhook availability for more notifications, so I can use the existing avenue that Google Chat has to allow notifications.

    There is probably another method for this notification that I haven't thought of yet, but regardless, this would be a great addition.

    Recently, it seems that Google Chat has reached some feature parity with Slack in that it has a defined integration avenue for adding notifications to Google Chat. I have found that I can set up a custom webhook to Google Chat for the CI jobs, but webhooks are not available on the other 2 features I am looking for notifications from.

    I would either like to have:
    a.) An integration for Google Chat with an app on the Google Chat side that we would add for the connection to our Gearset
    b.) Webhook availability for more notifications, so I can… more

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

20. Feature Request: Deployment Blocking Based on Daily Unit Test Job Status

    Currently, Gearset lacks a feature to block deployment CI jobs to the respective environments when the associated daily unit test job fails. Implementing this feature would be advantageous in ensuring that appropriate testing quality gates are established to prevent changes from being deployed in the event of test failures. This enhancement would significantly improve our deployment integrity and testing processes.

    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

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