Gearset's shared org credentials allow teams to build and deploy changes together. To make the most of this delegation, this article explains what access levels are required to perform actions in Gearset, such as opening a draft or deploying a validated package.
Delegating permissions is a feature of Gearset's Enterprise plan. Only users on an Enterprise subscription are able to manage and delegate their credentials, although users on a Pro subscription are able to use credentials that have been delegated to them.
Hierarchy of permissions
When a user adds a new org connection, they become the owner of that credential. Owners can manage delegation to other members of their team.
There are 4 levels of permission to an org that can be delegated to a user. In order of maximum level to minimum they are:
Deployment: full comparison and deployment access
Validation: comparison and validation access
Comparison: read-only access to run comparisons
None: no access
It is not currently possible to delegate access to Git repositories in Gearset.
The table below is an overview of the permissions a user needs to perform certain actions in Gearset.
In general, as long as a team member has comparison level access to the source org, the access level to the target org is what generally controls the ability to deploy, run, or refresh the job or comparison.
For the purposes of the table above, users have the
None level of access to any Git connections that they do not own themselves.
Even with delegated access to source and target, team members with Pro licenses cannot
- setup CI jobs,
- run other's CI jobs, nor
- deploy validated packages from CI jobs
For CI jobs which have git connections that Enterprise users do not own themselves, the access level can be considered as follows:
- if the git connection is the target, the user has None level of access
- if the git connection is the source, the user has Comparison level of access
This means that other members of a team can open and deploy drafts and validated packages that were created from Git as a source, so long as the target is a Salesforce org and they have the requisite permissions to that org.
Note that you cannot delete validated packages owned by other team members, even if you have been given full deployment access for the orgs in those validated packages.
Owner specific permissions
All team owners have the ability to edit the settings of all automation jobs (change monitoring, CI, and unit testing) as well as delete jobs.
Team owners still require the correct delegated access in order to run automation jobs.
Data deployments and org change monitoring jobs do not support delegated credentials
The use of delegated org credentials is not supported in Gearset's data loader or org change monitoring jobs. Users must use their own credentials to run a data deployment or to create or run an org monitoring job.
What happens when a user leaves a team
If a user who has delegated org credentials leaves a team, any org credentials they have delegated will be immediately revoked and set to
None for all other members of their team.
What happens when a user moves onto a Pro subscription
If a user who has delegated org credentials moves onto a Pro subscription (or no subscription), any credentials they have delegated will remain in their current state.
The user will no longer be able to manage these credentials or change the settings while they do not have an active Enterprise subscription.
Removing delegated org connections
Any member of the team can manually revoke their access to credentials that have been shared with them through the Salesforce orgs page in the
My connections section of the Gearset app.