1494 results found

1. Add "Open Branches" Tab to Development Sandbox Environments in Pipeline

   The only way to deploy an existing feature branch into a development sandbox is to perform a manual compare and deploy. Previously, we had our developer sandboxes set up as static environments which allowed us to create PRs against them for "re-deploy". This is not possible with the new Development Sandbox format. I suggest another tab be added called "Open Branches" which will allow the developers to select a feature to pull and work on in their development environment. That way we get the benefit of easy compare & deploy instead of having to manually compare and deploy. This will also support refreshes and inflight change development.

   The only way to deploy an existing feature branch into a development sandbox is to perform a manual compare and deploy. Previously, we had our developer sandboxes set up as static environments which allowed us to create PRs against them for "re-deploy". This is not possible with the new Development Sandbox format. I suggest another tab be added called "Open Branches" which will allow the developers to select a feature to pull and work on in their development environment. That way we get the benefit of easy compare & deploy instead of having to manually compare and deploy. This will… more

   4 votes

   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  ·  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. precision deployment for Record types

   precision deployment for Record types is required. currently when i try to deploy a record type gearset automatically adds all the picklist fields in that object. if we wanted to deploy only record type or only selected picklist fields currently its not possible. hence, precision deployment is needed for deploying record types

   4 votes

   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  ·  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. Allow configurable default settings for Jira integration

   Allow us to customize the default behavior for the Gearset<>Jira integration. Currently, Gearset posts a comment on the linked Jira ticket every time a commit is started and completed. This creates a lot of noise on the ticket.

   Currently the only way to customize the messages posted to Jira are on a ticket-by-ticket basis. Allowing an option to customize this at the org/pipeline level (e.g. only post a comment when a deployment succeeds) would be very helpful.

   4 votes

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

4. Remove full Run Apex Tests after promotion if the pre validation to a sandbox is successful for full test
   4 votes

   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  ·  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. Increase API call limits

   There currently is a API limit of only 10 calls per hour for the reporting and audit API's. This makes it difficult when developing and testing applications that tie into the api. In our case we use the api to pipe the data into our observability platform for reporting and dashboarding. It would be nice to either increase to something not THAT low or to have a development override option of some sort that customers to request to temporary increase. I understand the need for some limits due to having a shared cloud platform but this seems to be on the very low side.

   There currently is a API limit of only 10 calls per hour for the reporting and audit API's. This makes it difficult when developing and testing applications that tie into the api. In our case we use the api to pipe the data into our observability platform for reporting and dashboarding. It would be nice to either increase to something not THAT low or to have a development override option of some sort that customers to request to temporary increase. I understand the need for some limits due to having a shared cloud platform but this seems to be on… more

   4 votes

   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  ·  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. Notify when PR is automatically created (e.g. back propagation)

   Notify the developer when a Pull Request is automatically created. For example when next pipeline stage is reached and a PR is automatically created or when a back propagation PR is automatically created.
   A comment in related Jira ticket would be very helpful.

   4 votes

   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  ·  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. Implement a Ticketing Feature

   Salesforce DevOps Center has a useful feature that allows users to create different Projects that have their own pipelines. Within each Project, you can create Work Items (similar to Issues in Jira). The user can then perform their work in a Salesforce environment and then run a comparison to associate certain changes to respective Work Items.

   From there, each Work Item can be promoted through the various environments in the Project pipeline.

   This is really helpful when working on numerous tickets/features for a given project, knowing exactly which environment each Work Item is in and the various metadata elements that are associated with it.

   Gearset's comparison and migration tools are unparalleled, if this was possible, in conjunction with moving data for CPQ, Field Service etc projects, it would be immensely helpful and negate the need to utilize Salesforce DevOps Center

   Salesforce DevOps Center has a useful feature that allows users to create different Projects that have their own pipelines. Within each Project, you can create Work Items (similar to Issues in Jira). The user can then perform their work in a Salesforce environment and then run a comparison to associate certain changes to respective Work Items.

   From there, each Work Item can be promoted through the various environments in the Project pipeline.

   This is really helpful when working on numerous tickets/features for a given project, knowing exactly which environment each Work Item is in and the various metadata elements that… more

   4 votes

   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  ·  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. Bulk resolve merge conflicts

   We occasionally run into a situation where there are quite a few files with conflicts to resolve. We almost always are just wanting to accept all changes from the feature (not the environment). This takes an excessive amount of time through the Gearset UI to accept changes in every file. Would it be possible to add a button accepting all changes from feature across the entire PR?

   4 votes

   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  ·  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. Configure the "Saved Comparison Pair" to always use a specific Comparison Filter

   When managing multiple orgs, and running comparisons, the Saved Comparison Pair saves a lot of time. However, sometimes we need to use different Comparison Filters, based on which environments we are comparing.

   Instead of first choosing the Comparison Pair, then manually selecting the Comparison Filter to use, it would be great to be able to (optionally) configure the Comparison Pair to use a specified Comparison Filter.

   Example Use Case:

   When committing work from our Dev org to BitBucket, we exclude Apex Classes & Triggers, and mainly commit declarative functionality (Apex code is committed separately from our dev team). All development work (both declarative & apex) is then merged to the Stage branch, then deployed from there to our Stage/QA environment for testing.

   These are set up as separate Comparison Pairs, and each uses a different set of metadata comparison filters.

   When managing multiple orgs, and running comparisons, the Saved Comparison Pair saves a lot of time. However, sometimes we need to use different Comparison Filters, based on which environments we are comparing.

   Instead of first choosing the Comparison Pair, then manually selecting the Comparison Filter to use, it would be great to be able to (optionally) configure the Comparison Pair to use a specified Comparison Filter.

   Example Use Case:

   When committing work from our Dev org to BitBucket, we exclude Apex Classes & Triggers, and mainly commit declarative functionality (Apex code is committed separately from our dev team). All development… more

   4 votes

   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  ·  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. Improve audit API to extract list of users and their entitlements. Additionally, allowing us to provision & deprovision user access via API

    We use 3rd party tools to audit all of our user access at our company. Automating this via API instead of exporting CSV and loading that into another tool would be very beneficial. Additionally, we use that tool for provisioning and deprovisioning so if an API for that existed too, we could automate Gearset users.

    4 votes

    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.)  ·  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. Deployment pipeline view personalization

    Currently, the view in continuous integration (deployment pipeline) is sorted by ABC, which is not user friendly when there are many team members. In this case I appear last and I need to find myself in this screen.
    I suggest you to either:
    1. allow creating personal views per user, so I can see only my dev sandbox, full sandbox and production.
    2. change the scroll into a "regular" scroll, and not the current drag scroll

    4 votes

    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  ·  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. default repository

    Allow to set a default repository when you have multiple repositories.

    1. Navigate to Compate and Deploy
    2. Select Source Control and select a VCS(in our case Gitlab Self Managed)
    3. If you have dozens of repositories they all show up on the list
    4. Need ability to specific a default repo which will be auto selected
    4 votes

    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

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

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Enforce Promotion Approval Rules

    The current UI shows a green checkbox and allows you to attempt to promote changes between environments even if the merge request is unable to be approved. Looks like it in Gitlab there is an 'approved' attribute that may be able to be used.

    Alternatively, can have some basic rules but would like it called out its not ready to Promote in the Gearset UI.

    4 votes

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

14. Ability to export deployed components for specified period of time

    Instead of viewing it by deployment package, it would greatly help us to be able to export all components deployed during a specific period of time. It would help to include the following:

    Deployment friendly name
    Source
    Target
    Date and Time
    Deployment Status
    Owner
    Metadata Type
    Name
    Difference Type

    4 votes

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

15. Add option to "run tests if X is present" on CI jobs

    At the moment Gearset only offers an "all or nothing" option ("run all tests"), which is safer but completely ruins minor and cosmetic deployments (because it then takes half an hour to deploy even the smallest, inconsequent change like a Layout change) or "apex or nothing" option ("Default") which does allow for minor deployments to go through.. but also anything that's not Apex, which is dangerous because what if I'm deploying other automations like Flows? these changes would go un-tested.

    At the very least an option for "run all tests if Apex OR Flow is present" sounds mandatory. But ideally we should be able to select whatever metadata we like, personally I want all tests to run whenever we're deploying any automation change eg. Apex files, or Flow, or Processes, or Workflows, or validation rules, etc.
    But I don't need them to run if I'm just changing a Layout.

    Please can we get more options around what causes tests to run during a CI deployment or validation job?

    At the moment Gearset only offers an "all or nothing" option ("run all tests"), which is safer but completely ruins minor and cosmetic deployments (because it then takes half an hour to deploy even the smallest, inconsequent change like a Layout change) or "apex or nothing" option ("Default") which does allow for minor deployments to go through.. but also anything that's not Apex, which is dangerous because what if I'm deploying other automations like Flows? these changes would go un-tested.

    At the very least an option for "run all tests if Apex OR Flow is present" sounds mandatory. But ideally… more

    4 votes

    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  ·  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. Provide deployment options for Mulesoft via Gearset

    As Gearset does Salesforce based deployments so well, it would be great to have Mule deployments done through Gearset as well.

    4 votes

    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

    2 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. Flow equivalent of Static Code Analysis-esque rules

    Code Analysis rules run against Apex in Gearset. As Salesforce development continues to rely on Flows as the main tool for declarative automation, it's becoming challenging to catch known inefficiencies, known issues, and discouraged usages. It would really set Gearset a part as a deployment tool to utilize issue detection or run "rules" against Flow metadata to call out potential issues or flows not following best practices to even prevent a deployment or commit from occurring.

    Examples: SOQL or DML in a loop, the number of elements for flows (prior to api v57) or general overall complexity, lack of Descriptions on elements, using an Object filter in the start element of a scheduled-triggered flow then not writing the flow to run efficiently per $Record.

    Also attempting to deploy a flow with reference items that do not exist on the target - objects, fields, email alerts, email templates (Summer '23), etc. This happens on the Salesforce validation size, but only shows 1 error at a time like other validation errors, and would be really beneficial in the problem analysis step to catch missing dependencies ahead of time.

    I attempted to roughly tackle the first one with a script I could run locally in VSC/SFDX to analyze the current state of an org. However, being able to utilize this within a comparison and deployment as part of the Problem Analysis would be game changing, especially for larger teams where advanced admins often work independently and there's less opportunities for peer programming or peer review.
    https://github.com/MonicaBrie13/SalesforceFlowAnalysis

    Code Analysis rules run against Apex in Gearset. As Salesforce development continues to rely on Flows as the main tool for declarative automation, it's becoming challenging to catch known inefficiencies, known issues, and discouraged usages. It would really set Gearset a part as a deployment tool to utilize issue detection or run "rules" against Flow metadata to call out potential issues or flows not following best practices to even prevent a deployment or commit from occurring.

    Examples: SOQL or DML in a loop, the number of elements for flows (prior to api v57) or general overall complexity, lack of Descriptions… more

    4 votes

    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  ·  Problem analysis and deployment failures  ·  Delete…  ·  Admin →
    How important is this to you?

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. Deploy Managed Custom Filters Globally

    When we associate a custom filter with a particular CI job, and then make changes to the filter, give the user the option to push those changes to all jobs (list them out) that use that named filter.

    4 votes

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

19. Feature vs Release, Branch De-sync

    When Gearset detects that additional changes have been made to a feature branch AFTER the feature branch was already added to a Release, strange behavior may be experienced.

    Coming from a git background, I expected anything on the release branch would be ready to go on my deployment, but that is not what happened during my release window.

    Admittedly there were some features that had changes pushed to the feature branch after perhaps the feature branch should have been closed, namely after it was on the Release branch. However there's also an argument that we should trust whats on the release branch - what's on the release branch is what should be deployed.

    Without getting into that argument, I'll try to describe what happened during my deployment window and how I think it can be improved.

    I can't stress this enough, everything on the release branch was correct and ready to go to PROD. The method of applying changes to feature branches that were already on the Release appears to be the root cause of the issue in Gearset.

    Now the outcome that I want to avoid is what happened after I clicked the Deploy/Promote button on the Release in the Gearset UI.

    1. Click Promote
    2. Release is Validated and Apex Tests passed in PROD
    3. Release disappears from Gearset UI
    4. PRs start to open against PROD and UAT, many more against PROD than UAT though.
    5. PR Validation Jobs start running against PROD
    6. PR Validation Jobs end a considerable time later
    7. Deployment of the actual release begins

    It was only after the deployment into my PROD environment that I realized what had happened. And I had to learn it by smoke testing in PROD and piecing that together with the newly opened PRs against PROD.

    What I finally understood was that the package deployed for my release was not the contents of my release branch, but rather my release minus a handful of UAT feedback changes. These UAT feedback changes were made on the same feature branch and followed the same pipeline process as any other request, but because they had already been added to the release the additional changes were tracked separately inside of Gearset.

    Because this was tracked separately within Gearset, this needs to shift left. Teams shouldn't be surprised by this kind of change to their release in the midst of their deployment window. If Gearset determines that a feature cannot go in the release, that should happen before I click the promote button during my deployment window.

    When Gearset detects that additional changes have been made to a feature branch AFTER the feature branch was already added to a Release, strange behavior may be experienced.

    Coming from a git background, I expected anything on the release branch would be ready to go on my deployment, but that is not what happened during my release window.

    Admittedly there were some features that had changes pushed to the feature branch after perhaps the feature branch should have been closed, namely after it was on the Release branch. However there's also an argument that we should trust whats on the… more

    4 votes

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

20. Integrate with Linear

    Linear is quickly becoming the new Jira for today's technology and engineering teams. It should be considered an important integration.

    4 votes

    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

    2 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