1349 results found

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

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

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

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

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

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

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

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

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

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

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

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

13. View webhook pipeline settings and error history even when promoting

    When any pipeline is promoting most of the options in the pipeline settings menu are disabled, e.g. 'View Webhook Errors'.

    We want to be able to access these features, as we might need to reference a webhook error, and not have to wait until the pipeline is finished promoting. Our team is promoting at least one feature to one pipeline most of the day so we have to wait until after business hours to reliably access this information.

    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

14. Enable AccountContactRelation standard object as part of data deploy

    After chatting with support, it seems to be impossible to deploy an AccountContactRelation record when IsDirect = TRUE, meaning the AccountContactRelation is between a Contact and its primary Account.

    When I try deploying an Account record, Contact record and the AccountContactRelation record that joins them as top-level objects in the same deployment, I receive the error "INVALIDCROSSREFERENCE_KEY:You can't associate a private contact with an account.:ContactId --", presumably because in the order of operations, the Contact hasn't been updated with the Account lookup yet.

    When I try splitting this into 2 deploys, deploying the AccountContactRelation alone as part of a second deployment to an org where the Account and Contact records already exist, I receive the "DUPLICATE_VALUE:This contact already has a relationship with this account.:ContactId" error, because the AccountContactRelation was automatically created due to the Account being primary for the Contact.

    My organization uses multiple business-critical fields on the AccountContactRelation object, and we cannot find a way to populate them via data deploy, and have thus far resorted to manual population or separate dataloads.

    After chatting with support, it seems to be impossible to deploy an AccountContactRelation record when IsDirect = TRUE, meaning the AccountContactRelation is between a Contact and its primary Account.

    When I try deploying an Account record, Contact record and the AccountContactRelation record that joins them as top-level objects in the same deployment, I receive the error "INVALIDCROSSREFERENCE_KEY:You can't associate a private contact with an account.:ContactId --", presumably because in the order of operations, the Contact hasn't been updated with the Account lookup yet.

    When I try splitting this into 2 deploys, deploying the AccountContactRelation alone as part of… 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  ·  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

15. Enable use of multiple parent filters under 'Filter using parent object' in data deploys

    When the “Only deploy (object name) records that are children of the (dropdown of selectable objects) records that are being deployed.” checkbox is selected on the Account object settings screen of a data deploy, only one parent record can be selected. The ability to filter by multiple fields would be useful in my org.
    Use case: we have a custom object Beneficiaryc with lookups to 2 different objects: Asset_Groupc and FinancialAccountc. AssetGroupc and Financial_Accountc are both children of the Account object, so I’m able in one deploy to include Account records with all child AssetGroupc and FinancialAccountc records, but I have to choose between including all Beneficiaryc records that are children of deployed FinancialAccountc records or AssetGroupc records; I can’t include both. My current workaround is to do a second deploy just of Beneficiaryc records, but if the Filter using parent object feature had the flexibility of the standard Configure filter function with the ability to add fields and logic, we would be able to accomplish this in a single deploy.

    When the “Only deploy (object name) records that are children of the (dropdown of selectable objects) records that are being deployed.” checkbox is selected on the Account object settings screen of a data deploy, only one parent record can be selected. The ability to filter by multiple fields would be useful in my org.
    Use case: we have a custom object Beneficiaryc with lookups to 2 different objects: Asset_Groupc and FinancialAccountc. AssetGroupc and Financial_Accountc are both children of the Account object, so I’m able in one deploy to include Account records with all… 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

16. I would like the ability to auto promote updates to inflight feature branches

    When using feature branch promotion in pipelines, I often find myself in a scenario where I’ve pulled a new feature through the pipeline to one of my static environments. I then test it, discover something that needs to be changed, make the change in the dev environment, and pull that change through the pipeline again so it reaches the same static environment for retesting.

    I would like functionality that enables me to release a new change to that branch from dev and have it automatically promote through all static environments, stopping at the current one where the original pull request resides. This way I don't have to keep actively managing the pipeline and clicking promote every time it gets to a new static environment.

    When using feature branch promotion in pipelines, I often find myself in a scenario where I’ve pulled a new feature through the pipeline to one of my static environments. I then test it, discover something that needs to be changed, make the change in the dev environment, and pull that change through the pipeline again so it reaches the same static environment for retesting.

    I would like functionality that enables me to release a new change to that branch from dev and have it automatically promote through all static environments, stopping at the current one where the original pull request… 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. add preview of archived files and let admin choose fields to show on the related list in Archive Viewer

    Please improve Archive Viewer with a preview of the files Archived, like the current document viewer on SF and consider to add more functionalities on the related list shown on Archive Viewer, like choosing fields to show and search bar incorporated.
    These functionalities are already available with other Archive apps connected to SF.
    Let users select the record to restore directly from the related list in Salesforce.

    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

18. Using Back Promotion for single Environments only and selective PR's only

    We normally update our developer orgs with the "update sync" function after the PROD release. However, sometimes we have changes that are build on top of each other but developed by multiple devs and therefore orgs.

    In that cases, it would be nice to turn on "back promotion" but only for certain environments where it is needed and not globaly. In addition, being able to selectively create back promotions for PRs would be nice as well.

    At the moment, if the feature is activated, Gearset is creating a back promotion for every PR, regardless if it is needed or not. Which means after the release, you have to delete the ones that where not needed manually.

    Best would be to select a checkbox during "push" creation and also a option to create a back promotion after it already has been pushed.

    We normally update our developer orgs with the "update sync" function after the PROD release. However, sometimes we have changes that are build on top of each other but developed by multiple devs and therefore orgs.

    In that cases, it would be nice to turn on "back promotion" but only for certain environments where it is needed and not globaly. In addition, being able to selectively create back promotions for PRs would be nice as well.

    At the moment, if the feature is activated, Gearset is creating a back promotion for every PR, regardless if it is needed or not.… 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

19. Changing API Version should make it obvious to save filter before CI Job can be saved

    It's a usability bug, I think.
    When you change the API version in a CI Job, the button to save CI Job greys out but has a spinning dial of 'Something happening'. Actually the system is doing nothing, it is waiting for the filter to be saved (even if the filter wasn't saved before) but this is completely unclear.
    Changes then
    1. auto-save filter or bring up the 'save filter' modal
    2. Show a toast message saying "save filter"
    3. Button should grey out with hover text of "save filter", no spinner

    I waited longer than I care to admit, hoping the button would un-grey itself

    It's a usability bug, I think.
    When you change the API version in a CI Job, the button to save CI Job greys out but has a spinning dial of 'Something happening'. Actually the system is doing nothing, it is waiting for the filter to be saved (even if the filter wasn't saved before) but this is completely unclear.
    Changes then
    1. auto-save filter or bring up the 'save filter' modal
    2. Show a toast message saying "save filter"
    3. Button should grey out with hover text of "save filter", no spinner

    I waited longer than I care to admit,… 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  ·  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

20. Select All PRs for promotion

    When promoting PRs from one environment to another in the pipeline, it would be useful to have a "Select All" option

    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