1371 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

   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

2. Add ability to validate commit messages for deployments

   We require commit messages for deployments, but we actually need to go beyond this and validate the commit message format, checking for things like tagging ticket numbers in commit messages, formatting, etc.

   If the commit message validation fails, deployment should not be allowed.

   Some source control providers (e.g. GitHub) allow server-side pre-receive Git hooks which can perform such commit message validation; however, Bitbucket Cloud does not currently support this and it is unrealistic for us to switch source control at this point in time. Without this feature in Gearset we are unable to enforce formatting requirements on commit messages coming from Gearset.

   Example validation checks could include things like:
   - ensure minimum commit message length
   - check for patterns matching one or more regular expressions
   - etc.

   We require commit messages for deployments, but we actually need to go beyond this and validate the commit message format, checking for things like tagging ticket numbers in commit messages, formatting, etc.

   If the commit message validation fails, deployment should not be allowed.

   Some source control providers (e.g. GitHub) allow server-side pre-receive Git hooks which can perform such commit message validation; however, Bitbucket Cloud does not currently support this and it is unrealistic for us to switch source control at this point in time. Without this feature in Gearset we are unable to enforce formatting requirements on commit messages coming… more

   5 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

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.

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

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

5. Allow for Simplify Differences to be performed on metadata type before showing it as "different"

   Currently, Gearset performs a "Simplify Differences" on Clean data service and
   Connected app before reporting these metadata types as "Changed" in the comparison results.

   There are other metadata types, such as "Custom field" that sometimes show up as "Changed" in comparisons because the internal order of some of the tags are different in a sandbox vs production. Re-deploying these files from one environment to the other does not "fix" these differences. Gearset provides a "Simplify Differences" toggle in the UI that shows there is no effective difference with the file.

   It would be nice to provide a configuration toggle for metadata types in the filter settings to "Simplify Differences" as part of the Compare. When toggled, the compare would not report the item as changed if Simplify Differences results in no differences. (If this is too complex at the metadata type, provide a global toggle on compare and deploy to simplify all differences as part of the compare so that metadata items with no effective differences show up as "unchanged" in the compare results.)

   Currently, Gearset performs a "Simplify Differences" on Clean data service and
   Connected app before reporting these metadata types as "Changed" in the comparison results.

   There are other metadata types, such as "Custom field" that sometimes show up as "Changed" in comparisons because the internal order of some of the tags are different in a sandbox vs production. Re-deploying these files from one environment to the other does not "fix" these differences. Gearset provides a "Simplify Differences" toggle in the UI that shows there is no effective difference with the file.

   It would be nice to provide a configuration toggle for… 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

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

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

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

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

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

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

    5 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

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

12. Add an account setting to "Mute Live Chat"

    As an experienced Gearset user I'd like to mute the live chat so the pop-up notifications don't block buttons. Pop-up notifications have been rather disruptive.
    In particular:
    after selecting two orgs for a large compare operation, I try click "Compare", and walk away while the comparison runs.
    When I return to my computer, I discover that the compare never initialized, and it turns out that although I could see and click the button "Compare", it was behind a live-chat pop-up "Hi David,...", and the button would NOT execute until I closed the live chat pop-up (x) button.

    I'm experiencing an issue that was previously reported as a bug and marked as fixed, but it seems to have creeped in again, so I'm providing this as a longer term fix for the issue described in the related bug:
    https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/18993766-live-chat-button-overlays-action-button

    I hope the details help, and thank you for this fantastic product.

    Cheers!

    As an experienced Gearset user I'd like to mute the live chat so the pop-up notifications don't block buttons. Pop-up notifications have been rather disruptive.
    In particular:
    after selecting two orgs for a large compare operation, I try click "Compare", and walk away while the comparison runs.
    When I return to my computer, I discover that the compare never initialized, and it turns out that although I could see and click the button "Compare", it was behind a live-chat pop-up "Hi David,...", and the button would NOT execute until I closed the live chat pop-up (x) button.

    I'm experiencing an… 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

    0 comments  ·  Bug  ·  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. Add Webhook Error Logging and History for Outgoing Webhooks

    When configuring outgoing webhooks (e.g., to GitHub Actions or Slack), errors and failures are not surfaced to the user, making troubleshooting difficult and time-consuming. Currently, after a webhook is triggered (or fails to trigger), there is very limited visibility into what payload was sent, what response was received, or whether an error occurred. If a webhook fails silently or returns an error, I have no way to view detailed logs or the history of webhook attempts. Furthermore, error messages (if any) seem to clear out whenever CI job settings are saved, and there is no persistent record of webhook activity.
    This "blind debugging" increases the time and frustration required to resolve issues.

    Proposed Solution:

    Implement a persistent, searchable log or history for all outgoing webhook events in Gearset CI jobs, including:

    Timestamp of every webhook trigger (success or failure)
    Payload sent (with sensitive fields masked)
    Response code and body from the target endpoint
    Detailed error message if the webhook fails to send or receives an error
    Ability to manually re-trigger a webhook for testing
    Optionally, retain recent webhook logs even after CI job settings are updated

    This would empower users to quickly debug integration issues, validate payloads, and confirm that notifications and actions are working as intended. Having a clear audit trail of webhook activity

    When configuring outgoing webhooks (e.g., to GitHub Actions or Slack), errors and failures are not surfaced to the user, making troubleshooting difficult and time-consuming. Currently, after a webhook is triggered (or fails to trigger), there is very limited visibility into what payload was sent, what response was received, or whether an error occurred. If a webhook fails silently or returns an error, I have no way to view detailed logs or the history of webhook attempts. Furthermore, error messages (if any) seem to clear out whenever CI job settings are saved, and there is no persistent record of webhook activity.… 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  ·  Monitoring and reporting  ·  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. API to Manage CI Jobs

    I would like an API to manage CI Jobs and Sandbox connections.

    In our current workflow, we create new sandboxes and branches for large initiatives. Along with these, we need to connect the SB in Gearset, build the CI job, run it for the first time, and then tear it down when we're done.

    We would like to be able to automate some of this.

    1. I have a branch and a sandbox
    2. I want to connect that sandbox in Gearset (would be great to do this programatically via api)
    3. create a CI job via api
    4. be able to run the CI job via the api
    5. when done with our project, tear down the CI job

    I would like an API to manage CI Jobs and Sandbox connections.

    In our current workflow, we create new sandboxes and branches for large initiatives. Along with these, we need to connect the SB in Gearset, build the CI job, run it for the first time, and then tear it down when we're done.

    We would like to be able to automate some of this.

    1. I have a branch and a sandbox
    2. I want to connect that sandbox in Gearset (would be great to do this programatically via api)
    3. create a CI job via api
    4. be able to run the… 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  ·  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. API to Manage CI Jobs

    I would like an API to manage CI Jobs and Sandbox connections.

    In our current workflow, we create new sandboxes and branches for large initiatives. Along with these, we need to connect the SB in Gearset, build the CI job, run it for the first time, and then tear it down when we're done.

    We would like to be able to automate some of this.

    1. I have a branch and a sandbox
    2. I want to connect that sandbox in Gearset (would be great to do this programatically via api)
    3. create a CI job via api
    4. be able to run the CI job via the api
    5. when done with our project, tear down the CI job

    I would like an API to manage CI Jobs and Sandbox connections.

    In our current workflow, we create new sandboxes and branches for large initiatives. Along with these, we need to connect the SB in Gearset, build the CI job, run it for the first time, and then tear it down when we're done.

    We would like to be able to automate some of this.

    1. I have a branch and a sandbox
    2. I want to connect that sandbox in Gearset (would be great to do this programatically via api)
    3. create a CI job via api
    4. be able to run the… 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  ·  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. Add to Org Explorer the ability to search text within thing like Flows and Email Templates

    In addition to being able to search on the name. It would be helpful to also be able to search text within things like Flows and Email Templates. Like if you have the subject of the email template, but not the name of it to help find it.

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

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

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

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