7

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, Force.com 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.

6

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 Force.com Development Lifecycle.

3

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.

  • 1
    This is very important: Let the customers do the actual deployment if at all possible. That way there is some accountability on their part and it forces them to check your work. You can talk them through it, but if you can avoid making changes in their production org, do so. – DavidSchach Sep 9 '12 at 4:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.