Help us improve Gearset
We love getting feedback from our users on how we can make Gearset even better. Post your ideas for improvements, new features, and bug fixes alike, and vote for others – let us know what’s important to you.
1140 results found
-
Don't include Wave dataflow deletes in package when Recipe is included
When deploying deletes of Wave recipes, if you include the Dataflow at the same time, Salesforce will fail validation with a DataFlow not found error. GearSet should be smart enough to build the package without the Dataflow if the corresponding Recipe is marked for delete.
1 vote -
Schedule Delta CI Job to Run at Specific Time
I would like the ability to schedule a Delta CI Deployment Job at a specific time. We have a requirement to deploy at weird times every once in a while.
Code gets merged into our MAIN branch > Delta CI Deployment Job is disabled > click "run" on the job at specific time.
It would be great if someone didn't have to wake up at 3am to click the "run" button.1 vote -
Yellow help icon
i love the help you guys provide, really great.
Suggestion.. The yellow circle that you open and drop down.
1) can you move it to the header, and if there is a pending message show the yellow circle with a number in it ( number is count of pending messages )
2) can you make it a separate window model? typically when i am chatting, i need to see the entire screen and the current pinned model is usually in the way and i need to click the arrow to get rid of it.
If i could drag the window…1 vote -
Ability to turn rules/processes off as needed with ability to rollback
There are times when need to update data or load data into Salesforce org and need to turn off rules or processes before updating data or loading the data. When doing a data deployment, GearSet has this ability, and I would like to have this ability to do this without a data deployment. Ability to turn off Validation Rules, Required Fields, Restricted Picklist, Workflow Rules, Flows/Process Builders, and Triggers one by one or turn off all. Then roll back once finished updates.
1 vote -
1 vote
-
When cloning a deployment, also clone the test settings
When I'm cloning a deployment, if in the original one I have selected specific test classes, by default have those selected again in the clone.
Often you either need to repeat a deployment, or you'll deploy several times between instances, with the same tests.
1 vote -
Release Branches
If I create a Release Branch from UAT, I no longer need all the individual Feature branches.
Inspired by Gitflow and the current Gearset Expanded Branching Model.
Currently: The Expanded Branching Model will create a Feature Branch PR to main for every Feature branch that is merged to UAT branch.
Desired: When I create a Release branch from the UAT branch, then Gearset should close all the current Feature Branch PRs to Main Branch - if and only if the Feature branch was already merged to the UAT branch.
This is related to branch pattern matching because…
1 vote -
Gearset doesnt support Versioned Dataraptors for vlocity deployment
Gearset doesnt support Versioned Dataraptors for vlocity deployment.
Details provided to Valerio Chang1 vote -
Add ability to run sfdx force source status command for metadata deployment
It would be great if, when comparing an org to a repository, we could run the status command (sfdx force:source:status) to see the difference between a Salesforce org and the repository.
This command provides a list of files that changed to the user instead of performing a full (and tedious) comparison between the source and the target.
Having a list of changed files would make it easier for a user to see what change they made in an org, make it easier for them to not miss a file and would make comparison so much faster (since you would be…
1 vote -
Branch Pattern Matching
I want to use branch pattern matching to map CI Jobs to specific types of branches in my repository.
main
uat
dev
feature/*
release/*
hotfix/*
chore/*Each of these branch types can have different CI Jobs associated with them. Or in the case of a chore/*, maybe I want those branches to Skip CI Validation because it is an ops branch that doesn't contain any Salesforce components.
1 vote -
Pipeline CI jobs where deployment is disabled should capture validation job history
If you have a Pipeline CI job configured to be Run Job = disabled; you can still promote PRs and run validations (which is great). But the validation job history is not preserved under the CI job. In fact, AFAIK, it can't be found at all except for the current promotion's vcalidation
This would enable one to diagnose validation fails - perhaps due to problem analyzer automations. It would aid in communicating with support (as such validations could be shared)
1 vote -
Ability to test restoring of backup data periodically
It will be nice to have option to automate and test restoring of backup data periodically into a sandbox. Since it is going to be restoring production data to sandbox, there should be options to restore chunk of production data (due to the storage limitation with sandbox) and the metadata.
1 vote -
Provide and enforce branch naming conventions
Branches get all kinds of really stupid names over time. It would be nice if Gearset provided an option to template new branch names. For example when my users need to create a new feature branch for their user story, Gearset should prefix that branch with 'feature/'. When a release branch is created it should be prefixed as 'release/'. Bugfixes or Hotfixes could be bugfix/ or hotfix/.
Dictating naming conventions is unenforcable. Keeping branch names organized goes a long way to keeping the repository maintainable over long periods of time. Even if folks are well intentioned, git branches are case…
1 vote -
Ability to see complete history related to a ticket or common name
It would be incredibly useful to have the ability to see a complete history related to a ticket or common name. For example, if I'm working on a Jira ticket named "SALES-123," I would like to be able to see all of the comparisons, branches, deployments, and promotions related to that ticket.
This ability would significantly improve the efficiency and effectiveness of troubleshooting issues.
1 vote -
Ignore changes deployed to orgs from Gearset in Data Monitoring jobs
I would like to be able to monitor changes made to tracked metadata in our Production org, but without the "noise" generated from normal deployment changes (made via Gearset deployments). Basically, I want to catch changes made directly to Production that are unaccounted for in source control.
1 vote -
1 vote
-
edit problem analyser template
There should be an ability to edit the existing Problem Analyser Template. Else, one has to create the whole template again, re-do the changes on the template and then re-assign on all the existing Jobs which should use that template.
It is definitely going to save a lot of time and be beneficial overall.1 vote -
Enable a consistent, buildable set of Metadata for Releases
I'd like to have a way to work with a consistent set of metadata items for a release, that I can add, remove etc, and consistently deploy into a variety of sandboxes and ultimately Production.
Currently, if you clone a previous deploy, items are de-selected if they're the same between the environments being compared. That means once I've deployed, I can’t ever get that “list” of items back and I have to rebuild it every time.
A likely scenario is that I've deployed some metadata from Sandbox A -> B. Lets say it's 5 Apex classes. I then realize that…
1 vote -
language
Gearset UI Language specification. Allow users to specify which language they want the UI presented in and then show the correctly translated terms in that language. When using google to translate the UI the words it chooses are not always relevant.
1 vote -
Validation job when PRs are raised
Requirement :
Provide option to create a CI Validation Job only with "Validate pull requests targeting the source branch" and keep "Run Job" dropdown as optional .As Of Now :
When we raise a PR, it initiates feature branch validation ( cos, we enabled "Validate pull requests targeting the source branch" ), and after that when we merge feature-branch to target branch, it re-initiates another validation job.
For us, it's like similar validation is running twice on different events from which we can't opt out.Pros :
We can handle when to validate a feature branch, instead of bundling…
1 vote
- Don't see your idea?