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.
35 results found
-
Manage multiple Gearset teams from a single Gearset account
I want to be able to manage multiple Gearset teams from a single Gearset account, and not have to log out and log in again.
17 votes -
More granular permission settings for sub groups of a large team
Giving team owners/leaders the ability to define sub groups of team members and control their ability to deploy to certain environments.
For example not being able to connect to/make deployments to 'production' orgs.10 votes -
Ability to pause subscriptions for inactive users
Manage users on "My Team", so we can activate/deactivate users and then save on licences that are not used until reassigned.
6 votes -
Metadata Filter organization with group or tag management
It's great that we can set filter visibility now to Only Me or to share with Team. It would be nice, especially for larger teams, to have another way to organize them either with tags, folders, sub teams or groups.
Example: 1 Scrum Team may have 10-15 filters they maintain and use, and another group of users on a team also have 5 or so they use. Both can see all 20, and this adds up fast.
Feels like being able to group users together could also have other benefits like mass assigning access to orgs (for deployment, validation, comparison)…
5 votes -
Allows admins to limit the available branches of a repository
When connecting a source code control system, quite often an integration user account is used that may also be used for other parts of the enterprise. Please allow admins to restrict the available repositories and branches so that users can only run comparisons for the branches they should actually have access to.
5 votes -
Provide Audit Report of Org Connections and Who Access Has Been Delegated To
It would be great if we could pull an audit report that shows all of our Salesforce connections that are set up in Gearset and who has been delegated what level of access to each of them. This would help us to prove out segregation of duty for auditors by showing who has ever had access to deploy to production.
4 votes -
Ability to assign Data Deployment Entitlement through Shared Connections
We have a central Gearset Owner who setup our various orgs using a dedicated Integration User in each org. They then shared the connections with Gearset Users so the credentials remain hidden.
However, this only delegates metadata deployment entitlement, not data deployment. To allow data deployment, a User needs to remove the shared connection and set up the org connection themselves.
Data Deployment Entitlement should be managed as part of the shared connection, as well as Metadata Deployment Entitlement. This will maintain the ability for central management and also keep org credentials secure.
4 votes -
Provide account owners ability to control and lock certain features for team
Currently, there are some settings that we would like to turn on or off for the entire team. For example, the "Append Validation/Deployment items to ticket" toggles when doing a deployment. It is also unclear that when a team member changes these, they are changing the setting for the entire team, which leads to inconsistent Jira tickets, as some list the components and some do not.
We would like the ability for account owners to control these settings for the team and lock their ability to be changed by team members.
4 votes -
Microsoft Active Directory authentication for Gearset
Our company works with Microsoft tools and it would be very useful for us to be able to authenticate with Microsoft Active Directory. That way our security team only has 1 place to manage users for all our tools.
4 votes -
Expand the user security model to restrict user compare / deployment access to defined comparison filters
Hi guys -
In many instances, we would like to restrict user access to certain compare / deploy metadata filters. In our case, it would be rare that all metadata changes are to be deployed and we would like to give our engineers access to only certain filters. This would reduce the risk that items that should not be deployed at a high level will not be deployed. In the current model, if a user has deploy access, they can deploy anything and everything. This is what we are looking to avoid.
Thanks in advance for your time!
Best,
Richard
4 votes -
Environment variables - Clone
Hello Team,
We would like to have the possibility to clone already existing Environment Variables when setting up a new Environment.
This functionality will allow us to refresh and create new environments faster and prevent us from performing specific commits in branches and specific configs per new environment.
3 votes -
Limit who can connect Production or Specific Orgs
Our users may have access to certain orgs to do manual changes (we are working on reducing, but will probably never get to 0). Ability for us to block who can connect production can enforce usage of pipelines and prevent users from connecting their own user where they would get deployment access.
3 votes -
Support SAML-based SSO and SCIM-based user provisioning
To improve security, user experience and reduce user administration time, SAML-based SSO and SAML JIT provisioning or SCIM-based provisioning would be fantastic.
3 votes -
edit other team member's CI job
Have a way to edit other team member's CI jobs, if appropriate permissions are given.
3 votes -
Allow switching authentication provider (SSO)
I made the mistake of using the wrong SSO provider (Salesforce) on the main user account that owns all the pipelines, CI jobs, credentials, orgs, etc and now I'm stuck with it with no decent way of changing to Google, my preferred provider. Please create an easy way to switch SSO providers.
2 votes -
Users with access to same target org
2 users both have access to the same target org with different user accounts. User A creates a package and asks User B to deploy the package on their behalf. Unless User B has been delegated access to the same org they already have access to by User A's account then User B will be unable deploy the change as they receive the error
"To deploy you need deployment level permissions from the owner of the target"
Workaround to this security constraint was to download a copy of the package and deploy using Workbench.
2 votes -
Account owner should be able to delete templates created by others
If a team member is removed from Gearset team, any template or previous activity can not be removed by anyone else. Leaving some clutter behind. It would be good to have the Owner of the Gearset account/team to have a super admin level access to all templates/data created by other team members so clean up could be managed....
2 votes -
Add an option to share orgs by default
Where we have a developer-manager, and a team of developers, it would be useful to be able to have a default for sharing org-connections where the manager always has access to their team's orgs.
At the moment, we have to share each org one-by-one.
This has caught us out where a dev team member validated a deployment, then went on holiday thinking that we could deploy it for them. They forgot to share the org-access, so we had to recreate the deployment to get it done.
2 votes -
Allow optional parameters to the GearSet login url to support login method and custom domains if needed
When using Salesforce logins along with a custom domain, the current gearset login process requires 6 steps:
- go to https://gearset.com/
- Click "Log in" in upper right
- On the "Welcome back screen", click "Salesforce (Production, Developer)"
- On the Salesforce Login page, click "Use Custom Domain"
- Enter "customdomain" and click "Continue"
- Enter Salesforce Production Username and Password
If the GearSet login URL (from step 2) https://app.gearset.com allowed for optional parameters, a couple of the above steps could be eliminated
An example URL might be:
https://app.gearset.com?loginMethod=sfProdDev&customDomain=customDomain
or
Then that URL with the params could be saved as a favorite or placed in…
2 votes -
Allow bulk org access for new users, new org permissions upon adding
When adding a new user having the ability to give the same level of access to all orgs at once would be greatly beneficial.
Likewise, when adding a new org and having the ability to set user access to the new org would save time as well.
We are adding new orgs frequently and will be adding users as well. Saving time on permissions would be great!
2 votes
- Don't see your idea?