Working with Multiple Salesforce Orgs (Part I)
With the Spring 16 Salesforce release, Enterprise Edition customers now get 25 Developer Sandboxes, Unlimited Edition customers get 50, and Performance Edition customers get a massive 100 Developer Sandboxes – a big improvement from the single sandbox that Enterprise customers previously received. Now that you have them, how do you make the most of them?
Rules of Engagement
The best and worst thing about Salesforce is that it’s easy to customise your instance.
Many customers who adopt Salesforce don’t come from a software development and release management background. They see their sandbox as an area to experiment and try things out, but ultimately end up making changes directly in production.
As instances become more complex, this becomes a recipe for disaster. Get a workflow rule wrong and suddenly you’re spamming your users or – worse – your customers.
So the first step is to be comfortable that you will no longer be making any changes directly in production. No matter how simple the workflow rule may be. Of course, there are exceptions to this rule, such as building reports, list views, and so on, but everyone needs to understand the “rules of engagement” and adhere to them consistently.
The Change Pipeline
Every business using Salesforce should have a change pipeline. The most basic set-up has three orgs: a development org, a testing org, and a production (live) org. The goal is to make experiments in development, review changes in testing, and promote your final changes to production. This is all about minimizing the risk of making breaking changes while enabling Salesforce administrators to freely experiment and test out changes.
The DEV sandbox is where you make changes and try out small experiments. If you’re doing a major experiment that you may not move forward with, such as installing an AppExchange app, create a separate sandbox instead. DEV should have limited data and “System emails only” switched on. If you choose to import some sample data from Production, take steps to mask data any confidential or personal information about contacts.
The TEST sandbox should mirror PROD as closely as possible. In a healthy set-up, a successful TEST deployment is a strong indicator that deploying to PROD will be successful.
TEST prepares you for any issues that might occur when deploying to PROD. It’ll help you realise what you’ve missed in your change set and what manual post-deployment steps might be required. You may want to use a partial or full copy sandbox for this environment to have a larger sample of data copied across from production. Use Sandbox templates to configure exactly what data you want to bring across. Once changes are deployed to TEST then functionality can be tested and signed off in preparation for the next production deployment.
In a larger team or in an industry with rigid audit controls, you may want two environments – both TEST and QA. This separates testing from the dress rehearsal deployment. In this set-up, QA is more likely to have all the same integrations with third-party systems that production has.
The Production environment is what makes your business tick. Treat it that way. Try to have some structure to your deployments so that users aren’t seeing constant change. A good example I’ve seen is having a new production release on the first Thursday of each month. Occasional extra releases might be required to deal with production issues, but these should be reserved for true production issues and not minor inconveniences.
In Part II, we talk about expanding the pipeline for more complex set-ups, and how you can track changes and keep orgs in sync. Follow us on Twitter to get notified when new updates are posted.