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.
335 results found
-
API to provision users, assign users to connected organisations
API to provision users, assign users to connected organisations
It would be hugely benificial to us (60+ connected organisations, 25 employees working in teams for multiple clients at a time) if we could programatically provision/deprovision users and provide access to connected organisations via an api.
At the moment this is error prone manual work that has to be done by someone with high level access (and as such is usually already short on time).
6 votes -
track metadata filter changes
Filters are shared by default. However, if someone changes the filter, I cannot tell what has been changed, who made the change or when it was changed. Ideally, I'd like a version history for each filter.
6 votes -
Show Created By and Created Date when doing comparisons
When looking at a comparison it shows changed by as a column, would be helpful for consultants to Show Created By and Created Date as well
6 votes -
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…5 votes -
Allow multiple team members to be assigned to a single sandbox on the pipeline view
Currently a single team shared sandbox can have multiple users with delegated access. However, only one of the users can view the sandbox in a pipeline view. In order to allow multiple people to see the sandbox -
Current solutions:
- Add the same sandbox multiple times and assign each to the required team members
- Or, allow all team members to see all sandboxesSuggested solution:
- Allow multiple team members to be selected via the "Assign sandbox to team member" function.5 votes -
Make pre/post deployment steps conditional on developer sandboxes.
Pre/Post deployment notes can be set to pertains to various static environments but they always apply to sandboxes after a back deploy. This should be conditional-- most of the time I only set them applicable to prod and they aren't applicable to developer sandboxes.
5 votes -
Mass resolve auto resolved conflicts
Currently we have the auto resolve from previous environment feature which takes previous conflict resolution into account for a new conflict dectection run in a new environment. This is great but if I am deploying through a pipeline to multiple ORGs and the same conflicts that are auto resolved each time popup I need to keep clicking through them and marking as resolved.
I would like there to be a Mass resolve button that only resolves all the auto resolved conflicts. That way I dont have to click through each one even though everything is resolved already.
5 votes -
automatic pipeline deployment on successful validation
For Pipeline jobs, provide an optional feature (ability to toggle on/off) where if an Open PR has successfully validated on the target org, then auto deploy to target org. This is useful when propagating changes in downstream jobs. For example, once code review is done, a PR is merged into DEV by pipeline admin, but it should also automatically be merged and deployed into QA if the validation is successful.
5 votes -
Approval process for metadata deployment
It would be great to have a approval process for the deployment.
For example, once we have completed the comparison and validation, we can click a button "e.g.: Submit for Approval" and an email will be sent to a list of email.
In the email, receiver can review the summary of the deployment (e.g.: source org, target org, number of changed/new/deleted components, ...) and click on a link to approve or reject the deployment.
We can deploy only when the job is approved.5 votes -
Ability to recreate a reusable list or group for Deployment notifications
Every week we have a larger sized scheduled deployment for logic updates that runs after business hours. There's usually the same 2-6 people (often increasing) that want to receive an email and/or text message when the deployment succeeds. Whoever schedules the deployment has to add each one manually every time, and it would be nice to have a way to send notifications to a predefined list or group of email addresses and/or phone numbers.
It usually has to be the person that schedules the deployment, because if someone goes back to add their own email or phone to an already…
5 votes -
Ability to select source target for Successful Deployment Notifications
Currently successful deployment notifications send every success to the specified addresses. Having the ability to specify the source would eliminate the unnecessary notifications to those addresses. We have a use case in which we only wish to send notifications for successful deployments to our production source.
5 votes -
Mass delete of deployment and validation history
Would like the ability to delete multiple history items at once. The current process of clicking delete and then clicking the confirmation is cumbersome and time consuming when we have multiple users and multiple environments kicking off many CI validations through the day. Failure to clean up the Validation history, especially, eventually brings Gearset CI viewing to a crawl. Having the ability to delete multiple at once and/or a the ability to add a retention period for history would be ideal. Validation history is the most important because you can't filter by time period like you can when you go…
5 votes -
Validation Job to validate feature/* branch by scratch org creation
The idea is to validate feature branches in repo. For doing this it's necessary to allow specifying source branch by pattern (like feature/*) in "Add CI validation job" menu. The validation should check whether the code breaks the scratch org creation or not. This is valuable due to fragility of scratch org creation process (sfdx force:source:push).
5 votes -
Ability to use Sandbox Source Tracking features as opposed to a comparison filter
The comparison screen is great to help admins and declarative users see the changes they made. However, it still requires them to know which metadata to pull based on changes they made.
Source tracking in Sandboxes is in beta and would alleviate this concern.
https://help.salesforce.com/articleView?id=sfdx_setup_enable_source_tracking_sandboxes.htm&type=5
If Gearset could leverage this functionality (potentially leveraging SourceMember object or storing .jsons to track last modified times as local projects store) it would make the complete process easy to use for all alike (pull metadata, select diff, deploy).
5 votesWe’re currently working on a technical spike to incorporate source tracking capabilities into how we retrieve metadata. We’ll keep you updated on progress.
Regards,
The Gearset Team
-
Jira Integration: Include the option to add a comment in JIRA with the URL of the pull request created from Gearset + Assign reviewers
After a deployment to a git branch, gearset allows to create the pull request from Gearset. It would be nice to:
1. Have an option to add the pull request URL to the deployment notes
2. Have the capability of add reviewers (users from the git repo) into the Pull Request5 votes -
Modify the "Changed On" drop down filter groupings to round to the nearest day, rather than the exact time the change was made.
It would be helpful if in the "Changed On" dropdwn filter if it grouped it into days, rather than the exact time the change was made. Also, if there were preset groupings like "Today","Yesterday","Last 7 Days", etc.
5 votes -
Provide an option to run Aura and/or LWC testing before deployment
I don't think that very many people are actually creating Aura/LWC tests yet, but they really should be.
Since SF doesn't require them like it does for Apex, if we decide that those tests ought to be run before deployment, it would be great to have Gearset run them. This will help us to make sure they are run before every deployment instead of relying on developers remembering to do it manually.
5 votes -
Add default compare filter - Code changed by me today, changed by me last 7
A super common comparison done by a developer is to see only the Apex changes done by that developer today , or in the last x days
Since the last changed dates on Apex (VF, triggers, components) is super reliable whereas it is useless on Custom Field/Workflow), the suggestion applies only to Apex or code-type changes
Gearset would fetch only those code items changed in the last x days, then present in the difference viewer the changes pre-sorted in descending date order
This feature would eliminate multiple clicks just to deploy a handful of recently-made code changes in the comparison…
5 votes -
Allow option to select certain test classes to NOT run. Include an exclusion list of tests not to run
When deploying code, it would be nice to have an option of having an exclusion list of test classes to not run.
5 votes -
Please, please, please get US FedRAMP approval.
The ability to use this product for CI/CD and various other use cases in the US federal space would be a huge win for many agencies. I know the FedRAMP process is quite arduous, but the contractual potential here is pretty massive.
5 votes
- Don't see your idea?