1289 results found

1. Enable a consistent, buildable set of Metadata for Releases

   I'd like to have a way to work with a consistent set of metadata items for a release, that I can add, remove etc, and consistently deploy into a variety of sandboxes and ultimately Production.

   Currently, if you clone a previous deploy, items are de-selected if they're the same between the environments being compared. That means once I've deployed, I can’t ever get that “list” of items back and I have to rebuild it every time.

   A likely scenario is that I've deployed some metadata from Sandbox A -> B. Lets say it's 5 Apex classes. I then realize that I need layouts in there too. Ideally I can clone the previous deploy, add the layouts and deploy again. That way when it's time to deploy to a new environment, say Sandbox C or Production, I have a deployment to clone that has the Apex Classes AND the layouts. Currently I'd either need to build a new deployment by hand, or clone both deploys. That gets unmanageable fast.

   Currently what I do is maintain a Package.xml file with all the metadata items that are part of a release, and this list is added to/modified as I work on it with other developers. All deploys are done with this xml so that I know when I deploy it to Sandbox 1 and then Sandbox 2 it’s the same set of metadata every time.

   I'd like a way to clone deploys and keep all the previously selected items selected, even if they match between the orgs.

   Here is a screencast in case this is helpful: https://share.getcloudapp.com/jkuWzPA7

   I'd like to have a way to work with a consistent set of metadata items for a release, that I can add, remove etc, and consistently deploy into a variety of sandboxes and ultimately Production.

   Currently, if you clone a previous deploy, items are de-selected if they're the same between the environments being compared. That means once I've deployed, I can’t ever get that “list” of items back and I have to rebuild it every time.

   A likely scenario is that I've deployed some metadata from Sandbox A -> B. Lets say it's 5 Apex classes. I then realize that… 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

2. language

   Gearset UI Language specification. Allow users to specify which language they want the UI presented in and then show the correctly translated terms in that language. When using google to translate the UI the words it chooses are not always relevant.

   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. Validation job when PRs are raised

   Requirement :
   Provide option to create a CI Validation Job only with "Validate pull requests targeting the source branch" and keep "Run Job" dropdown as optional .

   As Of Now :
   When we raise a PR, it initiates feature branch validation ( cos, we enabled "Validate pull requests targeting the source branch" ), and after that when we merge feature-branch to target branch, it re-initiates another validation job.
   For us, it's like similar validation is running twice on different events from which we can't opt out.

   Pros :

   We can handle when to validate a feature branch, instead of bundling it with the CI validation Job ( Time based or source branch action based ).

   It will help us to validate and fix feature branch before merging it on the target branch.

   Requirement :
   Provide option to create a CI Validation Job only with "Validate pull requests targeting the source branch" and keep "Run Job" dropdown as optional .

   As Of Now :
   When we raise a PR, it initiates feature branch validation ( cos, we enabled "Validate pull requests targeting the source branch" ), and after that when we merge feature-branch to target branch, it re-initiates another validation job.
   For us, it's like similar validation is running twice on different events from which we can't opt out.

   Pros :

   We can handle when to validate a feature branch, instead of bundling… 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

   2 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

4. Consolidated Reporting for CI Jobs

   Hello. One item we struggle with is keeping track of CI Deployments that didn't fail, but didn't deploy as expected. The two causes we usually see are:

   1) Something was removed by problem analyzer
   2) We deployed something that Salesforce says succeeded, but no changes were made (e.g. deletion of picklist choices)

   We currently have about 100 CI jobs which makes it impractical to go into each one.

   The proposed format would look like a csv export:

   Job Name, Date, # Created, # Updated, # Deleted, # fixed by problem analyzer

   Opening a CI job history looks fine, but we'd benefit from being able to see all jobs on the same screen.

   Hello. One item we struggle with is keeping track of CI Deployments that didn't fail, but didn't deploy as expected. The two causes we usually see are:

   1) Something was removed by problem analyzer
   2) We deployed something that Salesforce says succeeded, but no changes were made (e.g. deletion of picklist choices)

   We currently have about 100 CI jobs which makes it impractical to go into each one.

   The proposed format would look like a csv export:

   Job Name, Date, # Created, # Updated, # Deleted, # fixed by problem analyzer

   Opening a CI job history looks fine, but we'd… 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  ·  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

5. Provide More Detailed Information on Data Deployment Summary Steps

   Currently the data deployment summary displays an elaborate interface but with very little useful information other than record counts. On the right side are Steps, but those steps do not tell the user much. I can see that in one step x records were fetched, for example, and in another step y records were fetched, but I can't see WHY.

   Example use case: I had a situation where I was filtering an object but the filter wasn't being honored (more records were being deployed than expected). I could see from the data deployment summary that one of the steps was bringing in additional records due to references but I could not determine what caused that step to get created (i.e. WHICH reference on which object in the deployment).

   Currently the data deployment summary displays an elaborate interface but with very little useful information other than record counts. On the right side are Steps, but those steps do not tell the user much. I can see that in one step x records were fetched, for example, and in another step y records were fetched, but I can't see WHY.

   Example use case: I had a situation where I was filtering an object but the filter wasn't being honored (more records were being deployed than expected). I could see from the data deployment summary that one of the steps was… 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  ·  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 a way so we can easily integrate commits into Salesforce.

   What I mean by this is, give users the ability to create and associate commits from in Gearset to a custom Object in Salesforce.

   The commit would create a new record in Salesforce, under the custom object, let's call it 'Commits'.

   We'd be able to pass through data such as the commit status, the ID of the commit, a link to the commit itself taking us back to Gearset, the name, and author, etc, etc...

   I'd imagine this is possible through the use of the BitBucket API, however with SF teams who lack developer resources, this would be a nice feature to have as it opens up visibility for the remainder of our team who may not have a Gearset account such as Product Owner,s BAs, and if needed, anyone else from the business.

   From Salesforce, we could filter through the commit message, for example, find the UserStory ID from inside the commit message and this is how it could be associated with a User Story record.

   What I mean by this is, give users the ability to create and associate commits from in Gearset to a custom Object in Salesforce.

   The commit would create a new record in Salesforce, under the custom object, let's call it 'Commits'.

   We'd be able to pass through data such as the commit status, the ID of the commit, a link to the commit itself taking us back to Gearset, the name, and author, etc, etc...

   I'd imagine this is possible through the use of the BitBucket API, however with SF teams who lack developer resources, this would be a nice… 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  ·  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

7. Allow Filters to be Customised in Pipelines UI

   Currently, you can create new filters in Compare & Deploy, but when you are comparing and deploying from within the Pipelines UI on your development org, you can only select existing ones. This either means you have to get your team to go into standard Compare & Deploy to set up specific filters first, or they always have to select the filter that includes everything.

   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

8. Change language to focus less on Source Controls and be more user friendly

   Gearset is great for non-technical users or those that find Source Control daunting. However, the terminology used in Source Control has leaked over to Gearset, and I think this detracts from the useful aspects of it, and at times just makes it feel like an extension of Source Control.
   e.g. "Create Pull Request" in the Pipeline UI should be labelled something more friendly like "Request Feature Deployment"

   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

9. Hide the "Create Pull Request" button on Deployment Success Screen

   Currently, we are setting our team up to use Pipelines, which has the benefit of guiding users down the pipeline in the right way (they can't create a pull request from a qa branch straight to main without going to uat for example). However, when they perform a commit from an org to a feature branch, the Deployment Success (commit success) screen has a button that allows them to create a Pull Request directly to any branch that they want. There should be an option to hide this from users, especially given the benefit of only being able to move from one environment to the subsequently mapped one in pipelines.

   Currently, we are setting our team up to use Pipelines, which has the benefit of guiding users down the pipeline in the right way (they can't create a pull request from a qa branch straight to main without going to uat for example). However, when they perform a commit from an org to a feature branch, the Deployment Success (commit success) screen has a button that allows them to create a Pull Request directly to any branch that they want. There should be an option to hide this from users, especially given the benefit of only being able to move… 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

10. allow field level granularity in CI Jobs

    Would like the possibly to set up a CI job that only syncs a sub-set of fields on a custom object. For example, we have an org to org sync where we want to update picklist fields but not autonumber fields. Currently we are running this job manually twice a day.

    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. Enable admin visibility into a Gearset team member's shared orgs

    As a Salesforce implementation partner (SI) I have a lot of organizations to manage, well over 50. Each time a new org is added, I can go through and add all the users to that org, but whenever a new person is added to my team, I have to go through each connection and add that user to the list.

    As the owner, I would also like to be able to see all the shared orgs inside my account, so I can centrally manage them, rather than just the ones that team members may have added.

    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

12. Prevent deployed validated packages from being deployed subsequent times

    Currently, after you deploy a validated package it no longer appears under the Validated Packages menu, however, if you still have the link for the validated package and navigate to that package it doesn't give you any indication that the package has already been deployed and allows the user to click the Deploy button again, assuming they have deploy permissions on the target org connection.

    As part of our production deployment approval process, we store the link to the validated package in our external ticketing system (https://app.gearset.com/validated-package-details?deployPackageId=<package id here>). When completing the ticket, users use that link to navigate to the package and complete the deployment. If multiple users happen to click on the link, you cannot tell if it's already been deployed. It seems like that page should prevent you from deploying the same validated package again, given that you can no longer access that validated package from the normal menu.

    Currently, after you deploy a validated package it no longer appears under the Validated Packages menu, however, if you still have the link for the validated package and navigate to that package it doesn't give you any indication that the package has already been deployed and allows the user to click the Deploy button again, assuming they have deploy permissions on the target org connection.

    As part of our production deployment approval process, we store the link to the validated package in our external ticketing system (https://app.gearset.com/validated-package-details?deployPackageId=<package id here>). When completing the ticket, users use that link to… 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  ·  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

13. Allow more than one instance of Jira to be connected to.

    It would be great to have the capability to connect to more than one instance of Jira. We are switching to a different instance and we have to delete and recreated the Jira connections each time we switch instances.

    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

14. Allow account admins to run reports on their team's usage of Gearset.

    I am managing a Gearset account and I need to be able to know who is using Gearset and who isn't so I can more properly assign licenses.

    This might be an Enterprise feature, https://app.gearset.com/account/account-report, but really should just be something an account admin can run.

    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

15. Pull Request From Deployment History

    Making a pull request via Gearset is only available from the Compare & Deploy Flow.

    I'd the link to make a pull request available from deployment history so that users can make the pull request to the various Git/Salesforce environments.

    Currently, I am telling my users to note the deployment id for their comparison and hit the link. This appears to work, but isn't user friendly.

    https://app.gearset.com/finished?deploymentId={deploymentId}&notify=true

    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

16. Show me where the Salesforce Release Changes are in the metadata files.

    As a gearset user, I want a guide to the location of metadata components created by Salesforce in each new release so that I don't have to guess and look for the metadata 3 times per year when Salesforce publishes changes to their platform.
    Please user your business relationships with product owners at Salesforce to submit this story idea on behalf of clients everywhere.
    For example, today I was looking for metadata, if any, created by enabling permission set expiration dates in my sandbox. This won't be availabe in production until release on 10/7 but I was curious if I could deploy it on release day or not. Typically, all these feature enablements are manual deployment steps.

    This could be a blog post three times per year but it would greatly help clients.

    As a gearset user, I want a guide to the location of metadata components created by Salesforce in each new release so that I don't have to guess and look for the metadata 3 times per year when Salesforce publishes changes to their platform.
    Please user your business relationships with product owners at Salesforce to submit this story idea on behalf of clients everywhere.
    For example, today I was looking for metadata, if any, created by enabling permission set expiration dates in my sandbox. This won't be availabe in production until release on 10/7 but I was curious if I… 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

17. enable UTAM

    In the same way you enable Jest tests to run during deployment like that:
    https://docs.gearset.com/en/articles/5204895-pilot-feature-source-control-setup-for-lwc-test-runs
    We would need to run UTAM tests:
    https://utam.dev/guide/introduction

    Those are stored in utam folder and as sucha re not deployed to Salesforce org but rather "ran" by the test system.
    UTAM is very similar to Jest but do a simulated browser test (including integrated services and login of users) that covers full scenario and several pages. It's possible by using Chromedriver through WebdriverIO. All these are nodejs libraries used by UTAM.

    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

18. Add feature for admin to disable all email notifications globally from the profile

    Add feature for admin to disable all email notifications globally from the profile

    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

19. Show expired orgs in list of salesforce orgs

    When checking my list of salesforce orgs it would be good to see that the listed orgs have valid tokens and if they don't have valid tokens either checked on the fly/daily etc or just from previous automation attemps/backup attempts this would really help when you have access to many sandbox orgs on your user account.
    https://i.imgur.com/j0qb4Bq.png Example possible implementation?

    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. Include Apex classes regardless of folder

    In GitHub, Apex classes don't always have to be in a folder called "classes " to work with them. Some people using SFDX put test classes in their own folder (sometimes called "tests". Even Apex classes within the "classes" folder can be sub-grouped into folders. (Example at https://github.com/trailheadapps/apex-recipes/tree/main/force-app/main/default/classes)
    I'd like Gearset to scan the entire repository and to group metadata by its actual type, not by the folder it is in.
    I'm not talking about the sfdx-project.json saying where the metadata is located. This is within each of those locations, it should find all Apex (for example). The Apex Recipes repo is a great example of that.

    In GitHub, Apex classes don't always have to be in a folder called "classes " to work with them. Some people using SFDX put test classes in their own folder (sometimes called "tests". Even Apex classes within the "classes" folder can be sub-grouped into folders. (Example at https://github.com/trailheadapps/apex-recipes/tree/main/force-app/main/default/classes)
    I'd like Gearset to scan the entire repository and to group metadata by its actual type, not by the folder it is in.
    I'm not talking about the sfdx-project.json saying where the metadata is located. This is within each of those locations, it should find all Apex (for example). The Apex… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

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