Sharing org credentials with team members

Delegating org access to allow other team members to deploy to your orgs

Valerio Chang avatar
Written by Valerio Chang
Updated over a week ago

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 an 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 Orgs to Members

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 organization 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.

  • 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 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.

Did this answer your question?