1373 results found

1. Ability to link a existing PR to service now task or Incident

   Currently Service now and gearset mapping only limited to Releases and Change Requests. In our company we use Requested Items, Request and Catalog Tasks, Incidents. We want Gearset PR Number to be linked Requested Item in Service Now .We want to display PR details on Requested Item in Service Now .

   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

2. Add Pipeline Functionality to Handle Environment Refreshes and Branch Realignment

   In many Salesforce development workflows, environments (especially static ones like UAT or SIT) are periodically refreshed from production. When this happens, the environment’s metadata and configuration can become out of sync with the branch linked in Gearset Pipelines.

   This especially occurs when:

   • Changes were made directly in production that didn’t flow through the pipeline, but now exist in the refreshed sandbox.
   • A deployment was started partway through the pipeline but never completed to production, leaving partial changes held on branches in the repo.

   Currently, the workaround is to manually run a comparison and commit the differences to realign the branch. However, doing this also triggers a CI job unnecessarily, adding extra time to the process. In these cases, no actual feature changes are being deployed the goal is simply to bring the repo branch back into alignment with the refreshed environment.

   Ideally, I would like a way for Gearset to re-sync the branch to match the main branch or the refreshed environment directly. While it’s possible to create a new branch to achieve this, that approach causes loss of history and requires additional setup effort.

   Proposed Enhancement:

   Introduce functionality within Gearset Pipelines to:

   • Automatically reset or re-sync the associated branch, API version, and metadata state to reflect what’s actually in the refreshed environment when a static environment is marked as refreshed.
   • Provide an option to perform this alignment without triggering CI or deployment actions.
   • Optionally trigger an automatic comparison or rebuild of the environment’s baseline for visibility.

   This enhancement would help maintain pipeline integrity after org refreshes, reduce manual work, and prevent unnecessary CI job runs when simply re-aligning environments and source control.

   In many Salesforce development workflows, environments (especially static ones like UAT or SIT) are periodically refreshed from production. When this happens, the environment’s metadata and configuration can become out of sync with the branch linked in Gearset Pipelines.

   This especially occurs when:

   • Changes were made directly in production that didn’t flow through the pipeline, but now exist in the refreshed sandbox.
   • A deployment was started partway through the pipeline but never completed to production, leaving partial changes held on branches in the repo.

   Currently, the workaround is to manually run a comparison and commit the differences to realign the branch.… 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

3. Introduce precision deployment for Experience Sites.

   We have multiple changes in train at any time across our three Orgs within our pipeline. We do not manage these changes via our pipeline due to some of the UI changes being made by Community Admins outside our Devops framework. At times we may have 3 separate features impacting a single page and we need to promote these changes separately. At the moment the Org to Org deployment takes the components in their entirety.

   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

4. Add support for Jira Service Accounts

   Jira has (finally) added Service Accounts, so that full Jira users are no longer required. Would be great to take advantage of this. For reference: https://support.atlassian.com/user-management/docs/understand-service-accounts/

   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

5. Need to store the Source record ID from source to target org

   When moving data from Org1 to Org2, The record ID from the source needs to be stamped in the target org in order to update that in the future, and this will be really helpful.

   Thank you.

   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

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

7. Change the test running options in pipelines

   The options for tests in CI jobs/pipelines don't seem to offer quite what I need for sandbox deployments. Specifically, I want to be able to run all the tests when class/flow/trigger metadata is changing but no tests when tests metadata do not change.

   This is possible to do when deploying to production orgs by using the "Salesforce default tests" option (see https://docs.gearset.com/en/articles/1376067-setting-apex-test-levels). But it is not possible in sandboxes.

   In sandboxes, the "Salesforce default tests" option runs no tests at all which I don't want. I also don't want to run "All your tests" because if merging a branch with only README.md changes I don't want all the tests to run since there is nothing actually being deployed. I can use "Specify tests to run" to limit the tests running to only those relevant to the metadata being deployed which works to an extent, but it means I can't run all the tests, only those matching the specific metadata.

   Ideally I want the "Salesforce default tests" behaviour for production orgs to be available for use on sandbox orgs too. I also note from the docs that the "Run no tests" option appears to be superfluous in CI Jobs - if its a sandbox, using the "Salesforce default tests" option achieves the same thing. If its production, that setting is ignored anyway and "Salesforce default tests" is used.

   The options for tests in CI jobs/pipelines don't seem to offer quite what I need for sandbox deployments. Specifically, I want to be able to run all the tests when class/flow/trigger metadata is changing but no tests when tests metadata do not change.

   This is possible to do when deploying to production orgs by using the "Salesforce default tests" option (see https://docs.gearset.com/en/articles/1376067-setting-apex-test-levels). But it is not possible in sandboxes.

   In sandboxes, the "Salesforce default tests" option runs no tests at all which I don't want. I also don't want to run "All your tests" because if merging a branch… 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  ·  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. 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

9. focus

   When viewing a Comparisons results and click the filter icon in the column header to filter that column, it would be nice for the focus to be automatically placed on the filter text so it can be typed directly (without having to click on the filter text field).

   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

10. checkbox

    When viewing Open Pull Requests in an environment in a pipeline, the user can click the checkbox beside the pull request thinking they have selected that pull request. Clicking the checkbox does not currently select that Pull Request in the UI. It would be nice if clicking the checkbox would also select the current Pull Request in case another function such as "Close pull request" (trashcan icon on right pane) is being selected.

    It is easy to think you have selected the pull request when clicking the checkbox for it and in turn close the wrong pull request as a result. For consistency, it would be nice to automatically select the current pull request when its checkbox is clicked.

    When viewing Open Pull Requests in an environment in a pipeline, the user can click the checkbox beside the pull request thinking they have selected that pull request. Clicking the checkbox does not currently select that Pull Request in the UI. It would be nice if clicking the checkbox would also select the current Pull Request in case another function such as "Close pull request" (trashcan icon on right pane) is being selected.

    It is easy to think you have selected the pull request when clicking the checkbox for it and in turn close the wrong pull request as 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  ·  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

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

12. svsvdv

    Dbbdbdvdbfbdbdv

    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  ·  Testing  ·  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. I would like to suggest a feature for Gearset that provides a more granular control over user permissions. Specifically, it would be benefic

    I would like to suggest a feature for Gearset that provides a more granular control over user permissions. Specifically, it would be beneficial to have the option to allow a user to commit changes to a branch but block their ability to create a pull request (PR). This would allow our team to review the commits before a PR is opened, providing a more effective way to manage and correct any potential issues before they impact the main repository. This is an improvement that would significantly streamline our workflow and reduce the risk of errors.

    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

14. Download multiple objects at once from a backup run

    Given the related nature of many objects within a Salesforce Org. It would be helpful to be able to filter on and select records from multiple objects in a single data download.

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

17. Add the ability to track who configuration changes to pipeline, CI jobs, etc...

    It would be nice to see when there's a configuration was changed such as required test configuration on a CI job or pipeline configurations.

    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

18. Add a link to open the deployment when a change is being promoted

    The pipeline view only shows that a deployment is "running" after promoting a change. It would be useful to have a link to the deployment job and be able to view the deployment status in gearset.

    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

19. Mobile Support

    Support mobile devices.

    The CSS Used for the Pipeline Environment popover prevents the browser from scrolling horizontally. You can try this be logging into Gearset on your phone's browser or by narrowing the browser width on your desktop.

    1. I want to deploy from my phone.
    2. I want to monitor PRs from my phone.
    3. I want to browse my Scheduled Jobs and Monitoring Jobs.
    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. Creating branch names from JIRA summaries can cause very long path names

    Gearset automatically creates a branch name from JIRA summaries. Windows paths are limited to 260 characters.

    error: cannot lock ref 'refs/remotes/origin/gs-pipeline/portal/SFBUS-33389/Update-Include-in-Export-formula-on-the-Intake-Criterio
    n-object-to-prevent-Intake-Tasks-and-Intake-Document-Checklists-from-pulling-when-associated-to-a-process-that-is-not-included-in-
    the-export-stage': Unable to create 'C:/Users/E19187/Repos/salesforce/.git/refs/remotes/origin/gs-pipeline/portal/SFBUS-33389/Update-Include-in-Export-formula-on-the-Intake-Criterion-object-to-prevent-Intake-Tasks-and-Intake-Document-Checklists-from-pulling-when-associated-to-a-process-that-is-not-included-in-the-export-stage.lock': Filename too long

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