The Salesforce.com platform provides organizations with a robust environment to manage constituents, clients, fundraising, programs and other activities. The key to benefiting from the Salesforce ecosystem is knowing how to leverage this environment to build and test new configuration, customization and integrations before they are introduced into your live Salesforce instance. Correctly using test and live environments allows you to produce innovative solutions to meet your organization’s needs, without endangering your day-to-day operations.
In this post we will dig into the basics of Salesforce architecture and how your organization can best manage a Salesforce environment.
A Few Key Concepts
The following concepts will help set the stage for the material in this post:
- Production Environment. This generally refers to the live system where your staff work every day. This environment is live, therefore any problems that might occur here will be noticed by staff, clients and supporters, and must be immediately addressed. Effective environment management is key to protecting the production environment by ensuring any changes have been fully tested before they arrive here.
- Sandbox Environment. A sandbox is any environment created – or “spun-off” – from the production environment. You use sandboxes for new development, testing, or staging to ensure work is ready to be deployed to the live – production – environment. Sandboxes come in different types, including full, partial and developer. Each type of sandbox comes with different considerations of data storage and cost.
- Change Control. As a concept, change control refers to the rules you must follow when moving changes from development to production. Your change control plan should define what testing occurs, how sandboxes are kept current, and who can move changes through the environment.
A Simple, Sample Salesforce Architecture
All organizations using Salesforce will have a live, production environment. All organizations should have at least one Developer sandbox spun-off of the production environment for new configuration. When a developer sandbox is created or refreshed (by clicking a button in the production org setup), it is an exact replica of the production environment, but without any data. A developer sandbox is no cost, but also has a limit on how much new data it can store.
An environment with Production and Development Layers is represented here:
Adding a Staging Layer to Salesforce Architecture
If you are using Salesforce as your CRM, you are likely using it to store constituent or client data. This data presents a host of new variables as to how new configuration may behave. To understand these variables, we recommend adding a Staging layer – with a complete data set- to your architecture. This approach will allow development to occur in a developer sandbox, but also provide a proving ground – with data – that closely resembles production. Testing new development against existing data in a full or partial sandbox surfaces any incompatibilities or conflicts before they cause problems for staff or clients in your live environment. You can prove your new work functions in a developer sandbox, but it is not until you see how it interacts with your data that you can truly understand how it will behave in the Live environment.
An environment with a Staging Layer is represented here:
The key is to control variables. It is generally unwise to create new configuration or customization in the Staging Layer. That work should be done in the developer sandbox and pushed to staging, so that the configuration for each instance is identical. The further development is from staging, the less likely you are to conduct effective testing in staging. The further staging is from production the less reliable it is as a proving ground for your work before it goes live.
Adding a Break-Fix Layer to Salesforce Architecture
Effective environment management is an exercise in caution. New features or functionality are built in a development environment, moved to staging for testing with real data, and then deployed to production with high confidence. This process is intentionally deliberative with the side-effect of being slow. When speed is a necessity, such as when a bug or break has been identified, your environment may require a break-fix environment. This could be a developer sandbox created to expedite changes that must be made to the live environment.
In this case, a bug discovered in production would be fixed in the break-fix sandbox, and deployed directly to production – by-passing both the developer and the staging sandboxes. After the bug is fixed and the production instance is fully operational, changes can be reconciled back to the developer and staging sandboxes. When daily operations have been compromised, the risk of working outside of the formal change control process is offset by the immediacy of resolving the issue.
An environment with a Break-Fix Layer is represented here:
It is critically important to limit the amount of work done in break-fix. This is not for new features or enhancements. If such work were to occur here it would undermine the integrity of your change control process. This is an emergency space that is better than trying to solve issues directly in production – but somewhat outside of the process for the sake of expediency.
Summary & Conclusions
In this post we introduced environment management on the Salesforce platform. Effective environment management protects your live environment. It ensures all changes are fully tested against configuration and data as closely resembling your live environment as possible. It is your change control process that will guide the use of environments and how change is managed, including when you need to quickly fix something broken.
If your organization is interested in further Salesforce projects or administration, get in contact with us.