187 results found

1. Feature Request: Deployment Blocking Based on Daily Unit Test Job Status

   Currently, Gearset lacks a feature to block deployment CI jobs to the respective environments when the associated daily unit test job fails. Implementing this feature would be advantageous in ensuring that appropriate testing quality gates are established to prevent changes from being deployed in the event of test failures. This enhancement would significantly improve our deployment integrity and testing processes.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

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

2. Install managed package from sfdx-project.json

   I would like to get the possibility to track my managed packages and their versions in the sfdx-project.json file and automatically install it from this file. Could this be a possibility?

   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

3. Adaption of Deployment frequency of CI jobs

   While setting up a CI job, I recognized there are only automatization options up to every 24 hours, which is once a day. Currently there is no possibility to deploy e.g. every second day or even more important to us, every week/ every second week. Please add this possibility when adding CI jobs, to have a slower Deployment cycle to e.g. demo sandboxes, that don't need daily 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  ·  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

4. Add Omnistudio Features to Scratch Org Features list

   When using the 'Create new scratch org' screen the following features are not available in the 'Scratch Org features' list

   OmnistudioMetadata
   OmnistudioRuntime
   OmnistudioDesigner

   These are available features according to the Salesforce documentation

   https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file_config_values.htm#so_omnistudiodesigner

   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

5. Pull Request Changed Items View Fix

   When viewing the items in a pull request in the 'Changes in this PR' section of the pipeline you only see the file name.

   I would like to see something more similar to an actual comparison view where you have a tab with one column for the name and then another for metadata type.

   Having just the full file name does not give me that instant information I need, especially when its a long file name and the type runs off the page never to be seen unless you hover over the file.

   Converting to a table format might also enable the ability to sort by name or meta data type which is very important when reviewing large deployments.

   When viewing the items in a pull request in the 'Changes in this PR' section of the pipeline you only see the file name.

   I would like to see something more similar to an actual comparison view where you have a tab with one column for the name and then another for metadata type.

   Having just the full file name does not give me that instant information I need, especially when its a long file name and the type runs off the page never to be seen unless you hover over the file.

   Converting to a table format might also… 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  ·  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

6. Trigger CI Jobs on Gearset deployments

   When setting up a CI Job originating from SFDC, we only have the option to trigger the job based on a time interval. Which makes sense since there are no events to subscribe to in SF for this.

   But, I think it'd be helpful to be able to trigger a job to run on the completion of another Gearset deployment. This would be useful for automating the addition of metadata items like fields or layouts into source control, which are less-than-fun to create as xml files.

   So rather than running such a job every 1hr, we'd ideally be able to run it any time we have a Gearset deployment into an environment, containing metadata specified in a filter.

   This would make it easier to bring admin users into our deployment lifecycle without them having to learn git.

   When setting up a CI Job originating from SFDC, we only have the option to trigger the job based on a time interval. Which makes sense since there are no events to subscribe to in SF for this.

   But, I think it'd be helpful to be able to trigger a job to run on the completion of another Gearset deployment. This would be useful for automating the addition of metadata items like fields or layouts into source control, which are less-than-fun to create as xml files.

   So rather than running such a job every 1hr, we'd ideally be able 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  ·  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

7. Save Problem Analyzer Changes to Deployment Set

   When using the Problem Analyzer to identify and fix issues within deployment sets, it's common to add or remove items to address specific problems. Currently, these changes are not automatically saved, which can lead to recurring issues in subsequent analyses.

   Suggested Enhancement:
   Introduce an option that allows users to save their modifications directly to the existing deployment set or create a copy of the set with these changes. This feature would streamline the problem-solving process and ensure that resolved issues do not reappear in future analyses.

   Benefits:
   Efficiency: Reduce the time spent on re-analyzing and re-fixing recurring issues.
   Consistency: Ensure that the deployment set remains up-to-date with the latest fixes and optimizations.
   User Satisfaction: Provide a smoother user experience by minimizing repetitive tasks and enhancing workflow continuity.
   This enhancement would greatly improve the usability and effectiveness of the Problem Analyzer tool.

   When using the Problem Analyzer to identify and fix issues within deployment sets, it's common to add or remove items to address specific problems. Currently, these changes are not automatically saved, which can lead to recurring issues in subsequent analyses.

   Suggested Enhancement:
   Introduce an option that allows users to save their modifications directly to the existing deployment set or create a copy of the set with these changes. This feature would streamline the problem-solving process and ensure that resolved issues do not reappear in future analyses.

   Benefits:
   Efficiency: Reduce the time spent on re-analyzing and re-fixing recurring issues.
   Consistency: Ensure… 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  ·  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

8. Option to create a CI job only for back propagation

   We created some CI jobs for back propagation of changes from Production to other downstream branches and orgs. But these CI jobs also pick up pull requests(from a different pipeline) for forward propagation.
   So, basically there is no way currently to create a CI job just for back propagation. It will be good to have a toggle in the CI job to mark it for forward or backward propagation

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   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

9. Automatic sandbox updates option

   The new sandbox updates process is really convenient - you can see all the updates a sandbox needs and apply one or more. However it is still very much a manual process to start it. We have a team of engineers and each one of them has to constantly go and trigger the update process manually whenever an update becomes available.

   It would be really nice if there was a switch for 'Automatic updates' i.e. whenever it is turned on, the updates are applied automatically during off hours.

   Of course if an update fails the engineer would receive an email as it is now and could tend to it on the next day.

   The new sandbox updates process is really convenient - you can see all the updates a sandbox needs and apply one or more. However it is still very much a manual process to start it. We have a team of engineers and each one of them has to constantly go and trigger the update process manually whenever an update becomes available.

   It would be really nice if there was a switch for 'Automatic updates' i.e. whenever it is turned on, the updates are applied automatically during off hours.

   Of course if an update fails the engineer would receive an email… more

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  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
   Planned  ·  AdminGearset Team (Feedback Manager, Gearset) responded

   This is currently planned for later this quarter and next.

   
   

   Users will have the option to:

   • Bulk update selected dev sandboxes
   • Automate developer sandbox updates; they will be immediately tried as and when ready

   
   

   If users want to automate dev sandbox sychronization now, they can use CI jobs to deploy changes from their desired source of truth - this comes with some risk of affecting work in progress though.

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

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

11. Add a Button to Retry Validation on Updates

    The new Updates feature is great, but there isn't a "retry" button when there are validation errors to resolve. It's not very intuitive to have to cancel the update and go start over to retry after fixing validation errors. Currently it just shows that the validation failed and the update can be cancelled. It isn't clear what to do after resolving the validation error, and a retry validation button would simplify the process.
    I had an error related to a manual change that needed to be enabled in my sandbox, and I had to cancel the update to get it to validate after making the change. A refresh option would have saved time, especially because I also had merge conflicts to resolve. After I made the manual change there was no way to retry the validation part, and I could only cancel which meant I had to resolve the merge conflicts again to proceed.

    The new Updates feature is great, but there isn't a "retry" button when there are validation errors to resolve. It's not very intuitive to have to cancel the update and go start over to retry after fixing validation errors. Currently it just shows that the validation failed and the update can be cancelled. It isn't clear what to do after resolving the validation error, and a retry validation button would simplify the process.
    I had an error related to a manual change that needed to be enabled in my sandbox, and I had to cancel the update to get it… 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  ·  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

12. Quick deploy in pipelines

    It would nice to be able to use the Quick Deploy feature once a release is validated, instead of either hitting deploy or scheduling the deploy and having it validate one again.

    22 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

    4 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

13. Precision Deployments for Lightning Web Components

    It is very much required to have Precision Deployment for LWC components as it is common to have multiple developers working on same LWC

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

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

14. Job Completion Percentage

    I would like to see more details about the status of a deployment or validation job in the Pipeline. Right now it just says job is running. I would like to see a estimated percentage of component validated/deployed against the total. Also maybe a running time estimate.

    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

15. Create a queueing system for the new sandbox updates process

    The new sandbox updates process, replacing long lived branches and back propagation in Gearset, is a really nice feature. However, it has limitations. I have found when trying to update multiple sandboxes at once using the updates feature, Gearset can only handle a couple before throwing an error and saying it is too busy and to try again later.

    I have 6 sandboxes in the pipeline all using this feature so I have to start two, wait for them to update and then start the next two and so on.

    If there was a way to set up a queueing system so that Gearset could work on them all without manual intervention, that would be ideal.

    The new sandbox updates process, replacing long lived branches and back propagation in Gearset, is a really nice feature. However, it has limitations. I have found when trying to update multiple sandboxes at once using the updates feature, Gearset can only handle a couple before throwing an error and saying it is too busy and to try again later.

    I have 6 sandboxes in the pipeline all using this feature so I have to start two, wait for them to update and then start the next two and so on.

    If there was a way to set up a queueing… 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

16. Let "member" create team-shared CI jobs OR let owner convert member's CI job to team-shared

    I see currently only team owners are able to create Team-Shared CI jobs. When my offshore team members who have "Member" role need to create a new CI job, their only option is creating a user-owned CI job, thus missing the benefits of Team-Shared CI jobs. All of our org connections are already Team-Shared. And we already have a Team-shared VC connection too. So, it'd have been very helpful if non-owner users with "Member" role could create Team-Shared CI.

    Alternatively, if that's not possible, next best thing would be - if team owners could convert any member owned CI job to Team-shared. But currently even that is not possible, as gearset throws an error saying only the owner of the CI (i.e. member who created the CI) can convert it.

    Please make either of these two options a possibility.

    I see currently only team owners are able to create Team-Shared CI jobs. When my offshore team members who have "Member" role need to create a new CI job, their only option is creating a user-owned CI job, thus missing the benefits of Team-Shared CI jobs. All of our org connections are already Team-Shared. And we already have a Team-shared VC connection too. So, it'd have been very helpful if non-owner users with "Member" role could create Team-Shared CI.

    Alternatively, if that's not possible, next best thing would be - if team owners could convert any member owned CI job… 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

17. Grouping developer sandboxes in Pipelines - back-promotion to a group

    Team,
    Currently Gearset Pipelines only offers the option to connect a developer sandbox group to a single downstream environment. While back-promotion to a group isn't available yet

    Could you please enable it ?

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

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

18. Improve visualization of multiple features being simultaneously worked on in a single developer sandbox.

    Currently, one must select (or create) a single feature+branch in the developer sandbox. The pipeline view only shows 1 active feature at a time. It would be nice visually see all of the features an individual developer is working on/assigned to.

    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  ·  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. Display pipeline webhook errors in Pull Request details

    Scenario:
    - Feature branch created, commits added, Pull Request opened and pushed part-way through the pipeline.
    - Pull Request has merge conflicts on one of the environments. Conflicts are addressed, but (let's say) PR fails validation so it is not promoted.
    - New commit is added to the feature branch.

    This commit will generally fail to propagate into the above mentioned PR branch (triggering a webhook error). It would be GREAT if that error were somehow displayed on the PR details screen.

    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  ·  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. Automate Jira Status when a Pull Request is created in Pipelines

    Presently, the capability to automatically update the Jira Status of a ticket is limited to transitions occurring between different environments in Pipelines. Enhancing this functionality to include automated updates triggered by the creation of a Pull Request would prove beneficial, eliminating the need for manual intervention when transitioning to stages such as "Code Review."

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

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