Gearset's shared org credentials allow other members of your team to view or deploy changes to one of your orgs without having access to your login details.
You can control what level of access they have to the org, and change or revoke access at any point.
Delegating permissions is a feature of the Teams or Enterprise license. Only users on a Teams or Enterprise license are able to manage and delegate their credentials.
Benefits of shared credentials
Sharing credentials allows teams to set up more complex workflows for their deployments and create approval gating.
For example, a release manager who has access to production could delegate the following access to their team, so they can approve any change before it is deployed:
Each developer is given validation level access to production. This allows them to run a comparison from their dev org to production, select changes they want to deploy, and create a validated package to check it builds successfully and all tests pass. Developers can't deploy directly to production, ensuring correct review before any change is released.
The release manager can then review the changes from the validated packages history, and when happy, deploy the changes out to production.
Setting up shared credentials
In Gearset, navigate to the My account section.
Select Delegate org access on the left-hand side under the ACCESS CONTROL
header.
Choose between Assigning Members to an Org or Orgs to a Member.
Assigning Members to a Salesforce org
With this chosen, owners can select team members to join a specific org. Multiple team members can be given access at once using the checkbox to the left of the display name.
Assigning Salesforce orgs to Members
Delegate org access section of our app allows Team Owners, or owners of specific Salesforce org connections, to delegate access level type (such as Comparison, Validation, or Deployment) to either:
Independent Salesforce org connections, such as org connections set up by specific members on your Gearset team.
Salesforce orgs used as target environment of CI jobs
Note: These could be either standalone jobs (not associated with any Gearset Pipeline), or CI jobs that are a part of a user-owned Pipeline in our app.
With this chosen, owners can select team members and assign orgs to them. Multiple Orgs can be selected using the checkbox to the left of the organisation type.
The four levels of permission are:
None
: the connection to this Salesforce org will not be shared with this team member. This is the default when a new team member or org is added.Comparison
: the team member can use this org for comparisons only. They cannot validate or deploy changes.Validation
: the team member can use this org for comparisons and create validated deployment packages. They cannot deploy changes.Assigning this permission will also include comparison permissions.
Deployment
: a team member has full comparison and deployment access to this org.Assigning this permission will also include comparison & validation permissions.
(For further details of access levels required to carry out different actions in Gearset, see our support article.)
You can assign different permission levels to different team members. If you change your mind, you can simply assign a different level of access (e.g. None
) to any team member.
Once you have shared an org with a team member, it will appear on their Salesforce orgs page (in the My Connections
section of the app), in a Connections shared with me
section, below the list of orgs they own.
The shared orgs will also be available to select in the metadata Compare and deploy page.
If they have the required permissions, they will be able to run comparisons, build validated deployment packages, or deploy changes as if they had authorised the account themselves.
If a user deploys changes to an org using a delegated account, the deployment will appear in Salesforce as if it was run by the original user who shared their credentials.
In Gearset, it will show the user with delegated access kicking off the job under the owners credentials.
Shared credentials are revoked if a member leaves the team
If a team member leaves a team, any shared org credentials are immediately revoked for all other remaining team members.
Shared credentials can be manually revoked
In the Salesforce orgs page (in the My Connections
section of the app), you can manually revoke access to orgs that have been shared with you.
Where it is not possible to use shared org credentials
Currently, you are unable to use delegated org credentials that have been shared with you to:
carry out data deployments
create new continuous integration (CI) jobs
create or run org unit testing jobs
create or run org change monitoring jobs
create or run data backup jobs
create environments in pipelines
It is possible to run CI jobs belonging to other users if the source is a Git repo and the target has the appropriate access delegated.