1377 results found

1. Ability for custom masking on Email fields

   Would love to be able to customize masking on email fields. When I currently mask an email field Gearset will make it something like 3d50b95f686844c6@gearset.invalid and I have no control over customization. I want to retain what the original email was so users can fix it and sent to it, if needed. I just want the email “broken” so it’s not used accidently through automation. Being able to customize the obfuscation would be very useful.

   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

2. Enable the ability to use Capturing Groups as part of the replacement in Environment Variables when using Regex

   Twice now we have run into issues with deployments that would be satisfied by having the ability to use the capturing groups of the Regex expression in the Environment Variable to populate parts of the replacement.

   A good example of this is usernames in Assignment Rules. Salesforce exports the assignment rule metadata from a developer sandbox without the sandbox name on the end. So, in the metadata file it has user@domain.com instead of user@domain.com.sbx.

   In criteria you can also be filtering on email addresses, so if you just look for @domain.com in the environment variable, it will also find email addresses in the criteria for the same domain. If this is the case, you can use a look-ahead format in the Regex to exclude those email addresses from the environment variable, but that means you have to match on the entire email address and not just the @domain.com part. Therefore, you need to include the full username in the replacement into the pipeline environments in order for them to be deployed successfully. If you capture that in a capturing group in the regex, you can simply use $1.sbx to change the user names to the sandbox relevant user names.

   This has come up in another use case as well, but it would just be useful to have as a tool in GS.

   Twice now we have run into issues with deployments that would be satisfied by having the ability to use the capturing groups of the Regex expression in the Environment Variable to populate parts of the replacement.

   A good example of this is usernames in Assignment Rules. Salesforce exports the assignment rule metadata from a developer sandbox without the sandbox name on the end. So, in the metadata file it has user@domain.com instead of user@domain.com.sbx.

   In criteria you can also be filtering on email addresses, so if you just look for @domain.com in the environment variable, it will also find… 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

3. Option to Export Full Comparison (Including JSON Metadata Differences)

   Currently, when exporting a comparison from Gearset, the CSV includes a list of all items from the comparison. However, the export does not include the JSON data that represents the metadata differences between environments.

   It would be extremely useful to have the option to export the full comparison, including the detailed JSON metadata diff.

   Use case:
   Our team is exploring ways to automatically generate changelogs whenever we make deployments. Being able to export the JSON comparison data would allow us to feed that information into an AI agent to generate a structured, human-readable changelog.

   Proposed enhancement:

   Add an option to export the full comparison data (including JSON metadata diffs).

   Ideally, make this available via both the UI and the API.

   This would open up powerful automation opportunities for teams looking to improve deployment transparency and release documentation.

   Currently, when exporting a comparison from Gearset, the CSV includes a list of all items from the comparison. However, the export does not include the JSON data that represents the metadata differences between environments.

   It would be extremely useful to have the option to export the full comparison, including the detailed JSON metadata diff.

   Use case:
   Our team is exploring ways to automatically generate changelogs whenever we make deployments. Being able to export the JSON comparison data would allow us to feed that information into an AI agent to generate a structured, human-readable changelog.

   Proposed enhancement:

   Add an option to… 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  ·  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

4. Create Templates for Data Backups

   During creation of Data Backups some requirement needs to be met across all jobs, so would be very good if we could replicate those requirements through a data back templae.
   In my example I cannot backup files, attachments, documents, etc, so I need to create a job using the recommended selection, then edit the selection removing the objects I don`t want and replicate this same process across all the existing and new jobs.

   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 backup  ·  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. Ability to link a existing PR to service now task or Incident

   Currently Service now and gearset mapping only limited to Releases and Change Requests. In our company we use Requested Items, Request and Catalog Tasks, Incidents. We want Gearset PR Number to be linked Requested Item in Service Now .We want to display PR details on Requested Item in Service Now .

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Integrations and connections (Jira, source control, DX etc.)  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

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

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

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

7. Introduce precision deployment for Experience Sites.

   We have multiple changes in train at any time across our three Orgs within our pipeline. We do not manage these changes via our pipeline due to some of the UI changes being made by Community Admins outside our Devops framework. At times we may have 3 separate features impacting a single page and we need to promote these changes separately. At the moment the Org to Org deployment takes the components in their entirety.

   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. Add support for Jira Service Accounts

   Jira has (finally) added Service Accounts, so that full Jira users are no longer required. Would be great to take advantage of this. For reference: https://support.atlassian.com/user-management/docs/understand-service-accounts/

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Integrations and connections (Jira, source control, DX etc.)  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

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

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Need to store the Source record ID from source to target org

   When moving data from Org1 to Org2, The record ID from the source needs to be stamped in the target org in order to update that in the future, and this will be really helpful.

   Thank you.

   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

10. Add Webhook Error Logging and History for Outgoing Webhooks

    When configuring outgoing webhooks (e.g., to GitHub Actions or Slack), errors and failures are not surfaced to the user, making troubleshooting difficult and time-consuming. Currently, after a webhook is triggered (or fails to trigger), there is very limited visibility into what payload was sent, what response was received, or whether an error occurred. If a webhook fails silently or returns an error, I have no way to view detailed logs or the history of webhook attempts. Furthermore, error messages (if any) seem to clear out whenever CI job settings are saved, and there is no persistent record of webhook activity.
    This "blind debugging" increases the time and frustration required to resolve issues.

    Proposed Solution:

    Implement a persistent, searchable log or history for all outgoing webhook events in Gearset CI jobs, including:

    Timestamp of every webhook trigger (success or failure)
    Payload sent (with sensitive fields masked)
    Response code and body from the target endpoint
    Detailed error message if the webhook fails to send or receives an error
    Ability to manually re-trigger a webhook for testing
    Optionally, retain recent webhook logs even after CI job settings are updated

    This would empower users to quickly debug integration issues, validate payloads, and confirm that notifications and actions are working as intended. Having a clear audit trail of webhook activity

    When configuring outgoing webhooks (e.g., to GitHub Actions or Slack), errors and failures are not surfaced to the user, making troubleshooting difficult and time-consuming. Currently, after a webhook is triggered (or fails to trigger), there is very limited visibility into what payload was sent, what response was received, or whether an error occurred. If a webhook fails silently or returns an error, I have no way to view detailed logs or the history of webhook attempts. Furthermore, error messages (if any) seem to clear out whenever CI job settings are saved, and there is no persistent record of webhook activity.… 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  ·  Monitoring and reporting  ·  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. Change the test running options in pipelines

    The options for tests in CI jobs/pipelines don't seem to offer quite what I need for sandbox deployments. Specifically, I want to be able to run all the tests when class/flow/trigger metadata is changing but no tests when tests metadata do not change.

    This is possible to do when deploying to production orgs by using the "Salesforce default tests" option (see https://docs.gearset.com/en/articles/1376067-setting-apex-test-levels). But it is not possible in sandboxes.

    In sandboxes, the "Salesforce default tests" option runs no tests at all which I don't want. I also don't want to run "All your tests" because if merging a branch with only README.md changes I don't want all the tests to run since there is nothing actually being deployed. I can use "Specify tests to run" to limit the tests running to only those relevant to the metadata being deployed which works to an extent, but it means I can't run all the tests, only those matching the specific metadata.

    Ideally I want the "Salesforce default tests" behaviour for production orgs to be available for use on sandbox orgs too. I also note from the docs that the "Run no tests" option appears to be superfluous in CI Jobs - if its a sandbox, using the "Salesforce default tests" option achieves the same thing. If its production, that setting is ignored anyway and "Salesforce default tests" is used.

    The options for tests in CI jobs/pipelines don't seem to offer quite what I need for sandbox deployments. Specifically, I want to be able to run all the tests when class/flow/trigger metadata is changing but no tests when tests metadata do not change.

    This is possible to do when deploying to production orgs by using the "Salesforce default tests" option (see https://docs.gearset.com/en/articles/1376067-setting-apex-test-levels). But it is not possible in sandboxes.

    In sandboxes, the "Salesforce default tests" option runs no tests at all which I don't want. I also don't want to run "All your tests" because if merging a 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  ·  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

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

    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

13. focus

    When viewing a Comparisons results and click the filter icon in the column header to filter that column, it would be nice for the focus to be automatically placed on the filter text so it can be typed directly (without having to click on the filter text field).

    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

14. checkbox

    When viewing Open Pull Requests in an environment in a pipeline, the user can click the checkbox beside the pull request thinking they have selected that pull request. Clicking the checkbox does not currently select that Pull Request in the UI. It would be nice if clicking the checkbox would also select the current Pull Request in case another function such as "Close pull request" (trashcan icon on right pane) is being selected.

    It is easy to think you have selected the pull request when clicking the checkbox for it and in turn close the wrong pull request as a result. For consistency, it would be nice to automatically select the current pull request when its checkbox is clicked.

    When viewing Open Pull Requests in an environment in a pipeline, the user can click the checkbox beside the pull request thinking they have selected that pull request. Clicking the checkbox does not currently select that Pull Request in the UI. It would be nice if clicking the checkbox would also select the current Pull Request in case another function such as "Close pull request" (trashcan icon on right pane) is being selected.

    It is easy to think you have selected the pull request when clicking the checkbox for it and in turn close the wrong pull request as 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  ·  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. Allow for Simplify Differences to be performed on metadata type before showing it as "different"

    Currently, Gearset performs a "Simplify Differences" on Clean data service and
    Connected app before reporting these metadata types as "Changed" in the comparison results.

    There are other metadata types, such as "Custom field" that sometimes show up as "Changed" in comparisons because the internal order of some of the tags are different in a sandbox vs production. Re-deploying these files from one environment to the other does not "fix" these differences. Gearset provides a "Simplify Differences" toggle in the UI that shows there is no effective difference with the file.

    It would be nice to provide a configuration toggle for metadata types in the filter settings to "Simplify Differences" as part of the Compare. When toggled, the compare would not report the item as changed if Simplify Differences results in no differences. (If this is too complex at the metadata type, provide a global toggle on compare and deploy to simplify all differences as part of the compare so that metadata items with no effective differences show up as "unchanged" in the compare results.)

    Currently, Gearset performs a "Simplify Differences" on Clean data service and
    Connected app before reporting these metadata types as "Changed" in the comparison results.

    There are other metadata types, such as "Custom field" that sometimes show up as "Changed" in comparisons because the internal order of some of the tags are different in a sandbox vs production. Re-deploying these files from one environment to the other does not "fix" these differences. Gearset provides a "Simplify Differences" toggle in the UI that shows there is no effective difference with the file.

    It would be nice to provide a configuration toggle for… 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

    2 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

16. svsvdv

    Dbbdbdvdbfbdbdv

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

18. Download multiple objects at once from a backup run

    Given the related nature of many objects within a Salesforce Org. It would be helpful to be able to filter on and select records from multiple objects in a single data download.

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

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