338 results found

1. Add Pipeline Functionality to Handle Environment Refreshes and Branch Realignment

   In many Salesforce development workflows, environments (especially static ones like UAT or SIT) are periodically refreshed from production. When this happens, the environment’s metadata and configuration can become out of sync with the branch linked in Gearset Pipelines.

   This especially occurs when:

   • Changes were made directly in production that didn’t flow through the pipeline, but now exist in the refreshed sandbox.
   • A deployment was started partway through the pipeline but never completed to production, leaving partial changes held on branches in the repo.

   Currently, the workaround is to manually run a comparison and commit the differences to realign the branch. However, doing this also triggers a CI job unnecessarily, adding extra time to the process. In these cases, no actual feature changes are being deployed the goal is simply to bring the repo branch back into alignment with the refreshed environment.

   Ideally, I would like a way for Gearset to re-sync the branch to match the main branch or the refreshed environment directly. While it’s possible to create a new branch to achieve this, that approach causes loss of history and requires additional setup effort.

   Proposed Enhancement:

   Introduce functionality within Gearset Pipelines to:

   • Automatically reset or re-sync the associated branch, API version, and metadata state to reflect what’s actually in the refreshed environment when a static environment is marked as refreshed.
   • Provide an option to perform this alignment without triggering CI or deployment actions.
   • Optionally trigger an automatic comparison or rebuild of the environment’s baseline for visibility.

   This enhancement would help maintain pipeline integrity after org refreshes, reduce manual work, and prevent unnecessary CI job runs when simply re-aligning environments and source control.

   In many Salesforce development workflows, environments (especially static ones like UAT or SIT) are periodically refreshed from production. When this happens, the environment’s metadata and configuration can become out of sync with the branch linked in Gearset Pipelines.

   This especially occurs when:

   • Changes were made directly in production that didn’t flow through the pipeline, but now exist in the refreshed sandbox.
   • A deployment was started partway through the pipeline but never completed to production, leaving partial changes held on branches in the repo.

   Currently, the workaround is to manually run a comparison and commit the differences to realign the branch.… 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. Add ability to validate commit messages for deployments

   We require commit messages for deployments, but we actually need to go beyond this and validate the commit message format, checking for things like tagging ticket numbers in commit messages, formatting, etc.

   If the commit message validation fails, deployment should not be allowed.

   Some source control providers (e.g. GitHub) allow server-side pre-receive Git hooks which can perform such commit message validation; however, Bitbucket Cloud does not currently support this and it is unrealistic for us to switch source control at this point in time. Without this feature in Gearset we are unable to enforce formatting requirements on commit messages coming from Gearset.

   Example validation checks could include things like:
   - ensure minimum commit message length
   - check for patterns matching one or more regular expressions
   - etc.

   We require commit messages for deployments, but we actually need to go beyond this and validate the commit message format, checking for things like tagging ticket numbers in commit messages, formatting, etc.

   If the commit message validation fails, deployment should not be allowed.

   Some source control providers (e.g. GitHub) allow server-side pre-receive Git hooks which can perform such commit message validation; however, Bitbucket Cloud does not currently support this and it is unrealistic for us to switch source control at this point in time. Without this feature in Gearset we are unable to enforce formatting requirements on commit messages coming… more

   7 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. I would like to suggest a feature for Gearset that provides a more granular control over user permissions. Specifically, it would be benefic

   I would like to suggest a feature for Gearset that provides a more granular control over user permissions. Specifically, it would be beneficial to have the option to allow a user to commit changes to a branch but block their ability to create a pull request (PR). This would allow our team to review the commits before a PR is opened, providing a more effective way to manage and correct any potential issues before they impact the main repository. This is an improvement that would significantly streamline our workflow and reduce the risk of errors.

   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. API to Manage CI Jobs

   I would like an API to manage CI Jobs and Sandbox connections.

   In our current workflow, we create new sandboxes and branches for large initiatives. Along with these, we need to connect the SB in Gearset, build the CI job, run it for the first time, and then tear it down when we're done.

   We would like to be able to automate some of this.

   1. I have a branch and a sandbox
   2. I want to connect that sandbox in Gearset (would be great to do this programatically via api)
   3. create a CI job via api
   4. be able to run the CI job via the api
   5. when done with our project, tear down the CI job

   I would like an API to manage CI Jobs and Sandbox connections.

   In our current workflow, we create new sandboxes and branches for large initiatives. Along with these, we need to connect the SB in Gearset, build the CI job, run it for the first time, and then tear it down when we're done.

   We would like to be able to automate some of this.

   1. I have a branch and a sandbox
   2. I want to connect that sandbox in Gearset (would be great to do this programatically via api)
   3. create a CI job via api
   4. be able to run the… 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

   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

5. Mobile Support

   Support mobile devices.

   The CSS Used for the Pipeline Environment popover prevents the browser from scrolling horizontally. You can try this be logging into Gearset on your phone's browser or by narrowing the browser width on your desktop.

   1. I want to deploy from my phone.
   2. I want to monitor PRs from my phone.
   3. I want to browse my Scheduled Jobs and Monitoring Jobs.
   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

   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. Restore feature branch when a mid-flight promotion branch is restored

   Have just experienced a scenario where closing a PR that is mid-flight in the pipeline caused the promotion branch and underlying feature branch to be deleted. So far, so good in terms of expected behaviour due to my pipeline settings. However, after restoring the promotion branch in order to reopen the PR and promote it in the pipeline, the next environment on the pipeline did not then show the change. This, I believe, was because restoring the promotion branch DID NOT restore the feature branch. Therefore there was no source to create a new promotion branch from in order to open a PR for the next environment. Feels like we are missing functionality whereby restoring a promotion branch should also restore the feature branch, especially if the restored promotion branch is mid-flight in the pipeline - which should be identifiable through naming convention of the restored promotion branch in relation to the pipeline.

   Have just experienced a scenario where closing a PR that is mid-flight in the pipeline caused the promotion branch and underlying feature branch to be deleted. So far, so good in terms of expected behaviour due to my pipeline settings. However, after restoring the promotion branch in order to reopen the PR and promote it in the pipeline, the next environment on the pipeline did not then show the change. This, I believe, was because restoring the promotion branch DID NOT restore the feature branch. Therefore there was no source to create a new promotion branch from in order 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  ·  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. Create a mass back propagation button

   Its very time consuming to have to back propagate one by one to each org. Please create a mass back propagation button.

   Also when back propagating where more than one connection to an org exists for instance our techdebt org has several admin connections and I have to hit update on all of them. Make the back propagation smart enough to know that it only needs one update rather than on each connection to the same org

   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. Ability to "Hide" Sandbox Groups on Pipeline Page

   In the Pipelines page, it would be very helpful if we had the ability to "hide" entire sandbox groups from view. This would make it much easier to quickly find and focus on the environments that are relevant to the logged-in user.

   Ideally, this "hidden group" setting would persist across logins and page refreshes, similar to how the "collapse group" feature currently works.

   I'm sure an "unhide groups" feature will be needed with this as well, in case a previously hidden group becomes relevant again.

   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. View Deployment Summary from Pipelines

   My team develops in siloed dev orgs. Once a feature is complete, we create a PR against an integration environment.

   This triggers a test suite run in the target org and a peer code review. This process works well for Apex. However, admins on our team build automations in Flow, which are nearly impossible to review in GitHub due to the complexity of the XML.

   To address this, we’ve been using Gearset’s Flow Navigator for Flow code reviews. Previously, it only took a couple of clicks to reach the Deployment Summary screen, and the Flow visualization made reviews much easier.

   After a recent UI update, accessing Flow visualizations now requires a longer, more manual click path:

   1. Click the environment and note the PR# for the Flow(s) to review.
   2. Go to CI Jobs.
   3. Expand the target environment.
   4. Locate the PR by number.
   5. Click Validation runs.
   6. Click View Summary.
   7. Click Back to results.

   That’s 6–7 clicks plus manual PR lookup. Much less efficient than before.

   Since Flows are a common part of development and Flow Navigator is a powerful review tool, it would make sense to add functionality in the Pipelines Open PR screen to quickly view branch contents and Flow visualizations directly in Gearset.

   My team develops in siloed dev orgs. Once a feature is complete, we create a PR against an integration environment.

   This triggers a test suite run in the target org and a peer code review. This process works well for Apex. However, admins on our team build automations in Flow, which are nearly impossible to review in GitHub due to the complexity of the XML.

   To address this, we’ve been using Gearset’s Flow Navigator for Flow code reviews. Previously, it only took a couple of clicks to reach the Deployment Summary screen, and the Flow visualization made reviews much easier.

   … more

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

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

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

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

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

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

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

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

    11 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

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

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

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

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

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