Find your content:

Search form

You are here

How does Salesforce recommend you log in to a customer's org when doing custom work for a client?


Every now and then I'm asked to do custom work in an org that I'm not a part of. I was wondering if there is some sort of best practice around getting in to do work temporarily.

The options as I see them:

  • If they use a managed package of yours they can grant you access through one of their accounts. The upside is it doesn't cost them a license spot, the downside is you don't have a security token so some tools (IDE, Explorer) are out of the question.
  • They give you your own login. This is probably best as far as flexibility but it costs them a license.
  • The give you another user's credentials. This is like the above except it doesn't cost them anything. Salesforce doesn't like people sharing accounts, however.
  • You only work in the sandbox and leave any production related stuff to the end user to deploy, configure, etc.

Is one of these options or an unknown additional option considered the "best practice"? I imagine SFDC would like people to use the second option but that seems a little overkill especially for a small customer who doesn't want to have to buy another license for a year so 1 person can work on something for a few weeks.

Attribution to: Ryan Elkins

Possible Suggestion/Solution #1

The best practice would be to have a dedicated user that uses a profile created specifically for development and not just the System Administrator profile.

If developing with a team of developers the best practice is for each of them to have their own username. I've found that sharing the same username for multiple developers in the same org is extremely frustrating. Here are some of the issues:

  1. Part of the user's web session is persisted, so breadcrumbs, tabs, apps, and navigation gets borked when more than one user is logged in under the same user name.
  2. It is harder to determine who was responsible for certain changes.
  3. It is harder to use the debug log simultaneously.
  4. Questionable wrt licensing.

If you are working with a client that will not give you your own username and it limits you then I would suggest factoring that into your price. I would try to aid the client in getting my work into production to see that it works and they have a positive experience.

See also An Introduction to Environments for some more development best practices and the Development Lifecycle.

Attribution to: Peter Knolle

Possible Suggestion/Solution #2

We generally follow your point:

You only work in the sandbox and leave any production related stuff to the end user to deploy, configure, etc.

So each developer gets their own login in the sandbox with no licensing issues generally as you just disable 'real' users to release user licenses.

Deployment is then either done by the end customer, or they create a user account for a nominated member of the developer team to do the deployment. This user account need only be enabled for a few days, again potentially disabling a 'real' user temporarily if licenses are really tight.

Attribution to: Joel Mansford
This content is remixed from stackoverflow or stackexchange. Please visit

My Block Status

My Block Content