1444 results found

1. ClickUp integration would be awesome!

   My company uses ClickUp to manage tickets, would be great if there was integration with Gearset as that would save me copy/pasting ticket references into the deployment descriptions.

   6 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

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

3. Export and Import Gearset metadata filters to other Gearset instances

   This idea feels relevant to Gearset customers that are consultants or in professional services teams.

   Our team will be managing multiple instances of Gearset for various clients. During the initial setup and also over the long term maintenance of those instances, it would be ideal to standardize the custom metadata filters being used. The base filters would be the same starting point for all instances, because of the references to namespaces and certain metadata types involved in our projects.

   Currently, the filters will need to be part of the post-instance setup steps. It would be ideal to be able to export them and import the filter config from other Gearset instances.

   This idea feels relevant to Gearset customers that are consultants or in professional services teams.

   Our team will be managing multiple instances of Gearset for various clients. During the initial setup and also over the long term maintenance of those instances, it would be ideal to standardize the custom metadata filters being used. The base filters would be the same starting point for all instances, because of the references to namespaces and certain metadata types involved in our projects.

   Currently, the filters will need to be part of the post-instance setup steps. It would be ideal to be able to… more

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

4. Need to be made aware and/or given the opportunity to view the totality of the changes prior to deployment

   Heres what happened, we deployed the Metadata AND a ChatBot. As part of our deployment, we manually updated the metadatas to contain PROD relavent info (instead of ACC info that was pushed from ACC Branch)

   I also discovered that there were duplicate utterances in the Chatbot which we had to remove via manual DML deletes to ensure that the Data Model was built properly.

   Then, we wanted to deploy just a Field change, and did so by merging a PR containt just the Field Change into main in Azure. This, obviously, triggered a deployment and in that deployment, the metadata and the ChatBot were redeployed in their incorrect form as we had not back propagated the manual changes.

   While we could/should have back propagated the Chatbot to remove the duplicates from the git branch version we dont want to move the metadatas back as we are only supposed to store keys and other sensitive PROD level info in the PROD environment only.

   I removed all the 'API Key' Metadata records from the Default Metadata comparison on the CI job so we shouldnt run into this again for those types of data, but I still think that we need to be notified and/or given the opportunity to view the totality of the changes prior to deployment somehow as it is unexpected behavior to deploy 5 things as a result of 1 file change and have to undo/repair all the unexpected changes.

   Heres what happened, we deployed the Metadata AND a ChatBot. As part of our deployment, we manually updated the metadatas to contain PROD relavent info (instead of ACC info that was pushed from ACC Branch)

   I also discovered that there were duplicate utterances in the Chatbot which we had to remove via manual DML deletes to ensure that the Data Model was built properly.

   Then, we wanted to deploy just a Field change, and did so by merging a PR containt just the Field Change into main in Azure. This, obviously, triggered a deployment and in that deployment, the metadata… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployment automation  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

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

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Set Problem Analyzer to default with all rules disabled

   Problem Analyzer rules are automatically enforced for CI Deployments which are misleading to end user as the default has ALL rules set to enabled. My recommendations is to have the default template have ALL rules set to disabled OR have clear communication in the CI Deployment feature to notify users that Problem Analyzer rules are enabled and may cause expected deployment behaviour/errors.

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

6. Integrate with Agile Accelerator instead of just Jira

   Integrate with Agile Accelerator instead of just Jira.
   It would be great if Gearset (and ideally the Pipelines-feature) could integrate with Agile Accelerator.

   Since we're a Salesforce-partner we want to use as many Salesforce-native solutions. That's why we've been happily using Agile Accelerator for many years.

   It would be great if Gearset can also integrate with Agile Accelerator instead of just Jira.
   Right now the Gearset Pipelines feature isn't useful to us, because of this sole reason.

   Thanks for considering this!

   31 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

   6 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

7. Add the ability to back up Salesforce Change sets

   While we use Gearset for our change sets, we have time where a 3rd party developer or a new admin uses standard Salesforce Change sets. We have had an incident where Hyperforce wiped out all of our change sets in all sandboxes, it would beneficial to add the ability to the backup to back up change sets

   1 vote

   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

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

9. Allow switching authentication provider (SSO)

   I made the mistake of using the wrong SSO provider (Salesforce) on the main user account that owns all the pipelines, CI jobs, credentials, orgs, etc and now I'm stuck with it with no decent way of changing to Google, my preferred provider. Please create an easy way to switch SSO providers.

   2 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  ·  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. Add navigation options to the data deployment process

    We are making use of the data deployment tool to seed our sandboxes with test data. When you execute a template it always navigates you to the last step (which makes sense). There are times however that we need to go back to the 2nd step and change filter criteria. This includes several clicks and waiting for pages to load.
    Is it possible to add a navigation bar at the top that shows the various steps so you can quickly jump to one you need to update?
    ie Step 1 > Step 2 > Step 3 > etc

    2 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  ·  Data deployment  ·  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. Improve Deployment Information in Notifications

    I've tried both Email and Teams integrations and the actual information in the message (or attached PDF for Email) is lacking, with only great piece being the branch name.

    An option to get advanced details that could provide some of the below (but not limited to):
    - Actual Links - Atleast with Gitlab Self-Managed, we just get a text-based message referencing a merge request.
    - Commits / Original MR - For those deployed via a Pipeline, getting the original MR (our pipeline is dev org > QA > UAT > Staging > Production, with the Dev Org > QA being the key "reviewed" MR. Showing list of commits deployed and their commit messages would provide an easy-to-read version of what was deployed.
    - Objects / Classes Deployed - Obviously this is untenable for large deployments, but even a list of metadata types deployed would be helpful.
    - Commiters & Reviewers - Showing a list of what users had commits and what users were involved in approving the Merge Request would also be ideal.

    I've tried both Email and Teams integrations and the actual information in the message (or attached PDF for Email) is lacking, with only great piece being the branch name.

    An option to get advanced details that could provide some of the below (but not limited to):
    - Actual Links - Atleast with Gitlab Self-Managed, we just get a text-based message referencing a merge request.
    - Commits / Original MR - For those deployed via a Pipeline, getting the original MR (our pipeline is dev org > QA > UAT > Staging > Production, with the Dev Org > QA being… more

    1 vote

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

12. Export Deployment History Additional Information

    It would be great if the Deployment History was able to provide details from Source Control. Specifically, list of people who approved tickets, branch names, commit IDs, etc.

    2 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

13. Better Automated Pipeline MRs

    The MRs that get opened for pushing the same work through pipeline aren't very helpful. Would love to link back to the original MR which would have more of the "approvals". Right now we end up having to re-approve everything like its from scratch. Insight and auditability (maybe even bringing up who approved the original MR/etc would be great)

    1 vote

    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  ·  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. Better Multi-Org Support

    We have 3 separate Production orgs for our company. It would be ideal if when we logged into Gearset we had a toggle to choose which production org and then all views, pipelines, connected orgs, etc. were filtered.

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

15. Granular Permissions

    Most of our users don't need to be doing any configuration outside of connecting their Dev Sandbox. Prefer to have more granular permissions to lock down features to smaller groups of users.

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

17. Show all Github requirements to merge in the Gearset pull request view.

    We have required approvals enabled on PRs in Github. Currently when viewing a Pull Request in the Gearset Pipelines view, it does not show that a PR is blocked from being merged because at least one code review approval is needed in Github. This leads to accidentally attempting to "promote" in Gearset and then the Pull Request merge fails. We would like to see these (and any other Github requirements) showing up in Gearset so we are informed which PRs are approved and ready to promote.

    10 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

18. Gearset VS Code Extension

    My development team spend their time in VS Code where they can see all their Git information etc. It would be great to have a Gearset plugin to stop them having to switch windows and allow them to have information at their fingertips. This could also encourage more developer use of Gearset.
    May display:
    - Build status
    - Static code analysis issues
    - View of pipeline

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  New feature  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. Include Pull Request title in the notification

    Hello GS team,

    Currently, the notifications from the pull request validations only include the PR number, I would like to request if it's possible to include the PR title.

    Current Sample: [Gearset] CI validation job Validation job for PR #11111 failed

    With the title in the subject of the notification, we can FW the results to the right teams automatically.

    Thank you!

    3 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

20. Gearset CPQ deployment to delete target org component if source is deleted

    Example in CPQ template you have situation when you need delete from source org component (content, line column etc.)
    Now you have to delete this in target org as post deployment task.
    Current solution support only new or changed component change.

    2 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