A Sandbox in Salesforce is an “almost identical” mirror copy of your production environment – with the choice of mirroring data or customizations or both. Enterprise customers can order up to 3 Sandboxes at an additional license cost. Performance and Unlimited customers get the first one included.
Why would a company need a Sandbox? As a technology services professional, I would recommend it as a best practice to maintain a separate non production environment to build, test, stage rollouts, investigate live issues, and train staff. Sometimes you may even want a demo environment to kick the tires around on features or Apps that you haven’t purchased yet.
As someone who has delivered software to Telecom operators servicing millions of users, I’ve seen all of these different types of environments, often as separate physical or virtual environments. With operational processes around how features and customizations move out through a build->test->stage->live cycle as well as how problem investigation moves backwards and the forwards again as a fix is found and implemented. Most Enterprise IT departments deploy a similar type of rigour. But I digress…
For an organization using a live SaaS platform like Salesforce, that is robust and highly customizable, and is exploring using different Apps or customizing features or wants to train new employees on the system, it is wise to have at least one second environment. In fact, it’s a best practice recommendation from Salesforce to use either a Developer or Sandbox when rolling out customizations or Apps. https://developer.salesforce.com/page/An_Introduction_to_Environments
Though Enterprise edition is considered the most popular edition, there are a lot of reasons why people might be using Group or Professional. Maybe your company is new to Salesforce and not ready to use all the features of Enterprise. Or the company has a limited budget and doesn’t want to pay the higher per-user Enterprise license fees. Or maybe you are an Enterprise edition customer that has made a business decision not to pay for the Sandbox feature. Or see the value in additional Sandbox environments than you want to pay for.
So what does a company in this position do to have this aditional environment? You can use a Developer edition. If you follow the Introduction to Environments link I provided above, this is okay with Salesforce as well. The “Developer edition would be ideal for you” bullets include “You are a salesforce.com customer with a Professional, Group, or Personal Edition, and you do not have access to Sandbox.” So I’m not recommending a fudge, but a suitable alternative. Though there is work involved in creating and maintaining a Developer edition – basically you may have to manually do what is available automatically in the Sandbox create and refresh.
Like most similar business decisions like this… you are often trading costs. The per-user subscription cost difference of the editions vs. the cost of time spent by your administrative employees. Initially, this might not be a bad thing. It does require the administrative staff to get to know your customizations intimately and instills an industry best practice ethos of managing technical change well.
So what are some of the things that you might need to consider in maintaining an secondary Developer environment.
Developer edition is free, which is great news for people with a limited budget. As mentioned above, free in terms of Salesforce licenses, but not free in terms of cost of employee time to setup and maintain it.
Developer edition has fewer user licenses. Developer edition comes with two standard user licenses. You should use one of these for an Admin user and one of these as a typical user with less privileges. This way you can administer the Developer environment, while still having a live production user experience.
If your production system has different kinds of users with different permission sets, then you may have to do a bit of manual work if you are using it to try things out or train these users. Though you can create these different kinds of users – and activate, deactivate them as you need them as you need them. The two standard user licenses apply to having two active users.
The users you create on the developer edition are still unique Salesforce ids, so you need to consider a naming convention that would not be needed on your live system.
And a few other limitations that deal with space available and number of transactions performed. Just something to be aware of in terms of what you can do and not do in the Developer environment. https://developer.salesforce.com/page/Developer_Edition
It will have features that may not be available in your production system. Developer edition has the feature set of Unlimited. Because it was created to help partners who are developing apps to be available to any Salesforce customer, then it can’t have restrictions.
This is great news if you want to test out things that are beyond your current license limitations to build the business case to move up. But something that needs to be considered when you are developing or customizing to make sure what you build works on your live production system.
You have to figure out how you will create test data. Unlike the Sandbox, you can’t mirror your live data instantly. The Developer environment will not have any meaning data. The good news is that you have the data import tools available that can help with creating data. So you may have to setup some test data load and delete procedures if you want to create data that would be meaningful when you are customizing or training users.
Whether you are the business owner who has pioneered using Salesforce in your organization, or the Administrator who has to perform continuous improvements and train new staff, I believe you can see a clear business case for having a second environment at your company. If you have to build that dollar and sense case, then consider a Developer edition as a strong alternative.