1357 results found

1. Enable multiple orgs to act as build agents for single pipeline step

   Occasionally our queue is backed up waiting for dozens of PR's to validate, this happens because a single org can only validate one PR at a time. It would be helpful for a solution that allows us to attach multiple orgs (sandboxes or scratch orgs) to a pipeline step such that multiple PR's could be validated in parallel. Then when a PR is deployed it could easily be deployed to all of the attached orgs.

   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

2. Solution for enabling parallel builds validations, i.e. multiple build agents

   Occasionally we have a backup in our queue PR validations where dozens of tickets all have to individually wait for there spot in line to validate. It would be great if we could spin up multiple orgs (sandboxes or scratch orgs) and attach them to a single pipeline element such that each org could help load-level the validation queue.

   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. Preserve Precision Selections through Fetching the Latest

   You're precision selections feature is absolutely amazing! Every time I use your tool it just gets better and better and this feature has me hooked. It's been huge with lightning web pages which often have multiple changes in UAT and need to be separated for deployment.

   We prep deployments before sending to UAT. Occassionally, there has been a big delay since the package was originally validated. If I need to go back to the original draft deployment and refresh the selected items to ensure I'm not overwriting something else that went out, the precision selections are cleared.

   1. There is a message that the precision selection is cleared - Thank You! It's helpful to know that happened.
   2. Once they get cleared, it's hard to remember which components had precision selection
   3. Once they get cleared, it's hard to remember which precision selections we're in the prior comparison for each component

   In a perfect world gearset could do something like a git rebase and attempt to apply the same selections with the current comparison. And when that isn't possible (as git rebase often is) to provide some route to have the original selections available for reference so I can confidently choose the correction selections with the current comparison.

   As an example, I have a lightning web page where I added a button to the highlights section and removed a component from the sidebar. After the refresh it could just show a brief diff of what was previously in there, auto-select it if the system can reason what it is, and if not flag it with context (e.g. removed component x from sidebar, not automatically mergeable, reselect manually).

   And short term, just some way to keep the components that were selected visible easily with a message that they previously had precisions selections would be a huge help.

   Thanks for the great work. Keep it up!

   ps - The fetch the latest is also one of my favorites. It's gotten so much faster to iterate on preparing deployments now that I can really precisely refresh just the metadata I know was changed!

   You're precision selections feature is absolutely amazing! Every time I use your tool it just gets better and better and this feature has me hooked. It's been huge with lightning web pages which often have multiple changes in UAT and need to be separated for deployment.

   We prep deployments before sending to UAT. Occassionally, there has been a big delay since the package was originally validated. If I need to go back to the original draft deployment and refresh the selected items to ensure I'm not overwriting something else that went out, the precision selections are cleared.

   1. There is a… more
   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

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

4. allow us to automate the PR Syncs after a shedule deployment occurs

   due to drift occurring because of the environments being out of sync after a deployment occurs I would love the capability to scheduel an automated PR sync after a successful scheduled release deployment occurs. like a checkmark box on a per sscheduled deployment basis.

   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

5. Using GitHub Apps to Replace Service Account for Team Shared Connection

   Problem Statement / Current Situation:

   For enterprise security compliance, organizations are moving to a model where all third-party integrations must use pure application-based identities (like GitHub Apps) instead of user-based accounts.

   Currently, Gearset's CI/CD jobs require a "Team Shared Connection," (https://docs.gearset.com/en/articles/8455568-team-shared-source-control-connections) which uses a combination of a GitHub App for authorization and a separate GitHub "service account" user for commit attribution. While this is a functional workaround, it still forces us to create, manage, and secure a user entity in GitHub. This goes against modern security principles that aim to eliminate the management of all user credentials, even for service accounts.

   Proposed Solution:

   We propose that Gearset enhance its GitHub integration to allow a GitHub App to be used as a complete, standalone identity for CI/CD operations.

   This would mean that when a CI job runs a merge, the author of the merge commit would be the GitHub App itself, not a separate service account user. This is an emerging best practice in the industry, as a GitHub App can have its own identity and be an actor within the system. As security expert Josh-ops notes in his detailed article on the subject, this provides a more secure and streamlined approach by "moving the identity from a user to the application itself."

   Problem Statement / Current Situation:

   For enterprise security compliance, organizations are moving to a model where all third-party integrations must use pure application-based identities (like GitHub Apps) instead of user-based accounts.

   Currently, Gearset's CI/CD jobs require a "Team Shared Connection," (https://docs.gearset.com/en/articles/8455568-team-shared-source-control-connections) which uses a combination of a GitHub App for authorization and a separate GitHub "service account" user for commit attribution. While this is a functional workaround, it still forces us to create, manage, and secure a user entity in GitHub. This goes against modern security principles that aim to eliminate the management of all user credentials, even… 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

   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

6. Enable Excel export of org differences—profiles, permission sets, and objects—in the same side-by-side format with change indicators

   I compared two profiles from different orgs—specifically, the old and new environments of the same company—to identify any differences and present them to the client for review and approval of necessary changes in the new org. However, I was unable to export the comparison results into Excel. It would be extremely helpful to have the ability to export the comparison data in the same structured and visual format as shown in the Gearset comparison window, making it easier to review and share with stakeholders.

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

7. Make components searchable across features in the pipeline

   If I know the name of a component, Can you give me a way of searching through the pipeline to see what features it resides in, where they are and when it was deployed please

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

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

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

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Deployment Failures in Pipeline

   The flow of a pipeline promotion is as such:

   1. Validate deployment to org
   2. (on success) Merge PR into base branch AND move PR to "Recent Promotion History" tab
   3. Deploy to org

   IF the deployment fails at that point, or is partially successful it would be great to denote that somewhere within the CI job within the pipeline. This would give the devs.admins more visibility into the true state of their features. Maybe we don't even move to the next environment until after a successful 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. Provide a visual indicator on upstream systems when out of sync with master

   Often times we see drift items added to PR's in our upstream systems. It would be nice to have an indicator that shows if a static branch is out of sync with master.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

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

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

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Automate upstream branch syncing

    After merging/deploying to prod allow auto-creation of sync PR's to upstream branches/orgs (QA, UAT, Staging, etc...). If the sync PR's could be promoted automatically that would be amazing.

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

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

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Automatically Backfill Dev Environments with Pull Request When Changes Are Promoted Downstream

    Description:
    Currently, Gearset’s pipeline tool does a great job of back-propagating changes between static environments when a change is made further down the pipeline. However, this behavior does not extend to developer environments, even if the change originated from a feature branch tied to that dev environment.

    Problem:
    If a developer starts work on a branch in their dev environment, and then that branch is promoted down the pipeline (e.g., through UAT, Staging, etc.), and changes are made to the branch further down (e.g., hotfixes, last-minute edits), those updates do not automatically get proposed back to the original dev environment.

    This leads to:
    - Dev environments drifting out of sync with the branch they were created from.
    - Increased manual effort to merge updates back into a dev environment.
    - A risk of bugs or inconsistencies when developers continue work unaware of downstream updates.

    Proposed Solution:
    When changes are made to a branch in a static environment further down the pipeline, and that branch originated from a dev environment, automatically create a pull request to update the dev environment’s branch with those changes.

    This would:
    - Keep the dev environment aligned with the true state of the branch.
    - Reduce manual syncing and the risk of drift.
    - Improve collaboration and awareness for developers working on long-lived branches.

    Description:
    Currently, Gearset’s pipeline tool does a great job of back-propagating changes between static environments when a change is made further down the pipeline. However, this behavior does not extend to developer environments, even if the change originated from a feature branch tied to that dev environment.

    Problem:
    If a developer starts work on a branch in their dev environment, and then that branch is promoted down the pipeline (e.g., through UAT, Staging, etc.), and changes are made to the branch further down (e.g., hotfixes, last-minute edits), those updates do not automatically get proposed back to the original dev environment.

    … 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

12. Add Monday.com as a source for User Stories

    Add Monday.com as a source for user story integration

    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

13. Add spell checker to CI/CD pipeline

    Spell checker helps maintain a high standard of accuracy, ensuring your content is reviewed in initial PR's itself. Just like how we use Clayton code feedback.

    If typos is in customer facing texts in UI (which is can be a big problem in public facing application where large no of users visits.)

    It would be good if spell checker can be added as a policy inside Clayton. So that we can find and fix issues easily.

    Advantages
    * We can also prevent potential PROD P1 errors.
    * Enhanced Code Quality
    * Improved Deployment Efficiency
    * Reduced Technical Debt

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

14. Enhancement Proposal: De-merge Option for Gearset Branch Management

    Currently, Gearset provides a helpful feature to merge branches, which is ideal for creating a Release branch that bundles all related components. However, it would be a valuable enhancement to introduce a de-merge or selective unmerge capability. This would allow teams to easily remove specific feature branches from a Release branch particularly useful in scenarios where some stories are pending approval or need to be excluded from the release at the last minute.
    Such a feature would improve flexibility during final release preparation and reduce the need for manual branch adjustments or rework.

    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. Deploy CustomLabel by label separately

    The automated deploy (CI) filter does not have the resources to deploy isolated CustomLabels, so that specific labels can be included or excluded.

    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. Delete Flow by Version Number

    It would be beneficial to delete specific inactive flow versions. Examples where this would help streamline deployment changes:

    • You need to delete a custom field that is used in a flow. You create a new version of a flow, remove the dependency on the custom field and activate the new flow. Now you want to remove the flow version that still has the custom field dependency. Something like a checkbox to select the version(s) to remove.

    • You have inactive versions of a flow and you want to clean up the historic flow versions. Something like a checkbox to select the version(s) to remove.

    It would be beneficial to delete specific inactive flow versions. Examples where this would help streamline deployment changes:

    • You need to delete a custom field that is used in a flow. You create a new version of a flow, remove the dependency on the custom field and activate the new flow. Now you want to remove the flow version that still has the custom field dependency. Something like a checkbox to select the version(s) to remove.

    • You have inactive versions of a flow and you want to clean up the historic flow versions. Something like a checkbox to select the… more

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

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

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Add folders to Data Deployments for better organization

    To help with organizing data deployment templates it would be great to have some sort of folder structure to allow us to group data deployments by team. We have several Salesforce Teams at my company and we all have slightly different data deployment needs. It would be great to have team folders for data deployment templates...for example Sales Team Templates, Service Team Templates, Marketing Team Templates, etc. Today we use some naming conventions which is fine, but would be a little cleaner if we had a folder structure. Thanks for your consideration.

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

18. load more items

    Please stop using "Load more items..." as the way to load more table items. It's very annoying to have to say show me the last 30 days but then click the button 20 times to get there.

    I'm referring to the Promotion history page but anywhere this concept is used should be ripped out.

    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. Add a feature to ignore queue members when deploying queues

    When deploying Queues with Gearset the members section is automatically included and the member list is deployed to the target org. Gearset has a suggested fix to sync the queue members with the target environment but it doesn't always work.

    Salesforce supports deploying queues with an empty list of users as queue members are more like data than metadata I suggest a feature toggle in Gearset where the users section of the queue is ignored for deployments to preserve the user list in the destination org.
    Our company and many others probably maintain the queue users directly in production as it's done with public group membership.

    Here is an excerpt of the xml and what to remove to preserve the queue members in the target org.

    <?xml version="1.0" encoding="UTF-8"?>
    <Queue xmlns="http://soap.sforce.com/2006/04/metadata">
    <doesSendEmailToMembers>false</doesSendEmailToMembers>
    <name>QueueNameTest</name>
    <!-- Remove from here
    <queueMembers>
    <users>
    <user>bla@blabla.com</user>
    </users>
    </queueMembers>
    Remove to here-->
    <queueRoutingConfig>Test</queueRoutingConfig>
    <queueSobject>
    <sobjectType>Case</sobjectType>
    </queueSobject>
    <queueSobject>
    <sobjectType>LiveChatTranscript</sobjectType>
    </queueSobject>
    </Queue>

    When deploying Queues with Gearset the members section is automatically included and the member list is deployed to the target org. Gearset has a suggested fix to sync the queue members with the target environment but it doesn't always work.

    Salesforce supports deploying queues with an empty list of users as queue members are more like data than metadata I suggest a feature toggle in Gearset where the users section of the queue is ignored for deployments to preserve the user list in the destination org.
    Our company and many others probably maintain the queue users directly in production as… more

    4 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

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

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. give personal settings

    personal settings to adjust the following:
    auto populate deployment notes from feature branch over to the pull request deployment notes on create pull request screen
    auto set checkboxes on create pull request screen (skip CI validation checkbox etc etc)
    set default target branch other than main branch on create pull request 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  ·  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