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.
Shared credentials are an Enterprise feature.
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.
From the drop-down menus, choose a Salesforce org that you want to share and one of the four permission levels for each of your team members.
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.
Deployment: a team member has full comparison and deployment access to this org.
(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 authorized 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 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.