Salesforce Sandbox – Managing Changes in Production

What is Salesforce Sandbox?

Salesforce Sandbox is a risk-free environment for simulating configuration changes, but how can you tell when it’s safe to skip it and go straight to production?

Every organization using Salesforce has a production or “live” org and a set of sandboxes. Developers employ the production organization, which has live data. Salesforce Sandboxes are replicas of the production org. They do not contain any live data or active users.

If you have recently refreshed your Salesforce Sandbox, you can use it to make changes since it has the same tools and functionality as your live org. But, you should keep in mind that any effects caused by those changes in the sandbox will also appear in the live environment. While it may seem overwhelming to work in the sandbox at times, it does not eliminate the need to deploy your work to the live environment. Therefore, it is crucial to know when it is safe to make changes live and to take the necessary measures to implement those changes correctly.

Skipping Salesforce Sandbox, Why Not?

You must be handling dozens of requests daily. New metric requests are coming from directors. Bugs are coming from the customer service department. The sales team has its change requirements too. Sometimes it might feel a lot quicker and easier to go ahead and make the needed changes in your company’s live org. However, have you considered who or what else might be impacted by those changes?

There are often knock-on effects when changing things in sandbox Salesforce. For example, validation rules may block a workflow you’ve created. Alternatively, someone may be using a field you are trying to remove. Before making changes, you must ensure you’ve assessed all potential effects.

———-

_{You might also like our blog}
5 Challenges when Deploying New SFDC Changes

———-

Salesforce Sandbox or Live: A Process of Elimination

To decide whether to use Salesforce Sandbox or Live for a change, the first step is to assess the nature of the change. If the change requires coding, then you must use a sandbox since you cannot write code directly into a production org in Salesforce. However, if it can be achieved through configuration, it’s best to test it using automation tools in a Salesforce sandbox environment first. This will ensure that automation does not affect live data. When removing an element, it’s always preferable to use sandboxes to prevent data loss. This is because missing elements are often referenced in workflows or code.

For creating new issues in configuration, some higher impact changes like new objects, record types, and page layouts are best done in sandbox and rolled out later. However, there are quite a lot of new configurations that are doable without causing any consequences to others or loss of data, such as new fields, picklist values, reports, email templates, profiles, or roles. Nonetheless, it’s important to take precautionary steps before implementing these changes to avoid any unforeseen issues.

Sandbox Production: Do It Right

So, you have decided that you can make the changes in the production org. We recommend taking the following steps. They help to ensure adoption and avoid negative impacts.

• Double-check. Make sure what you’re doing isn’t going to have any unwanted direct or indirect impact.
• Communicate. Always be sure to communicate changes to your team before making them. Do not surprise anyone in your organization with changes. Moreover, double-check to ensure no one else is using your changes for other purposes.
• Phase release. It’s always best to get other admins, superusers, or the change requester to validate your change. Do this before releasing it to the rest of the organization. The phased release approach helps confirm if your change fits the intended purpose. Otherwise, it will allow you to make adjustments before the wider team uses it.
• Training. User training is vital, whether it is a short ‘how-to’ guide or a live training session. It helps in getting users on board with your change. Training allows you to explain the change and how best to apply it.

Salesforce Sandbox: Do It Right

So, you have decided that you can make the changes in the production org. We recommend taking the following steps. They help to ensure adoption and avoid negative impacts.

Change Request	Environment	Considerations
I need a new picklist value for a custom picklist on our accounts.	Live	Data entry picklists usually have little impact on other components, especially when adding new value.
We have added a new step in our sales process. Now we need a new picklist value for opportunity stages.	Sandbox	This feature will likely be used globally, so it needs careful consideration before being changed across the business.
I want a new custom text field on Leads to capture more details.	Live	Make sure you check that lead mapping is set up for this field.
We need to send an email alert to customers.	Sandbox	You don’t want to send emails to the wrong people or with inaccurate content.
Whenever a salesperson closes an opportunity, I’d like to update the relevant field automatically.	Sandbox	You should test any workflows or process builders before live deployment.
I need to create a new standard product.	Live	Don’t forget to set the price books up for the new product.
I use CPQ and need to create a new product.	Sandbox	CPQ is a very complex add-on to Salesforce and should only be set up and changed in a sandbox. Each product can have many components.  Each component can be connected to many different rules.
I want to create an approval process for discounts on opportunities.	Sandbox	Approval processes are like workflows. They impact multiple users and records and will often require a lot of testing to get right.
I need permission to make changes to a particular field.	Live	It’s worth checking whether this is a specific use case. Do all other users with the same profile require this permission? This can make the difference between a permission set or a profile change.
I want to add a new component to a dashboard.	Live	Dashboard components are sourced from reports. Therefore, you would have to create the report first. An excellent way to make and change reports and dashboards is in a private folder. Once created, move them to a public folder.
I need to add fields to a page layout for a specific profile.	Live	Creating a field will give you a choice to add to any page layout. However, the best practice is to go into the specific layout and place the field exactly where you want it.

———-

_{You might also like our blog}
Salesforce Testing: 5 Tips for UAT and Functional Testing

———-

What are the different Sandbox types in Salesforce?

Developer Sandboxes

Developer sandboxes are  intended for development and testing tasks in an isolated environment. A Developer Sandbox includes a copy of your production org’s configuration (metadata).

Developer Pro Sandboxes

Developer pro sandboxes are intended for development and testing in an isolated environment and can host more extensive data sets than a Developer sandbox. A Developer Pro sandbox includes a copy of your production org’s configuration (metadata).

Partial Copy Sandbox

A Partial Copy sandbox is intended to be used as a testing environment. This environment includes a copy of your production org’s configuration (metadata) and a sample of your production org’s data as defined by a sandbox template.

Full Sandbox

A Full sandbox is intended to be used as a testing environment. Only Full sandboxes support performance testing, load testing, and staging. Full sandboxes are a replica of your production org, including all data, such as object records, attachments, and metadata. The length of the refresh interval makes it challenging to use Full sandboxes for development.

Salesforce Sandbox: Always First

The best way to reduce risks resulting from any changes is to try them in Sandbox first. Next, test and deploy to production. We recommend using a change management tool. Such a tool can help you follow the Sandbox process or make changes straight to production. For example, check out Panaya’s ForeSight for Salesforce.

 Salesforce ForeSight delivers the data you need. It shows you the effect on any elements due to the changes you’re looking to make. ForeSight is a valuable tool when trying to assess whether to make specific changes in live or not. It enables you to end guesswork—and risks—before going into production.

ForeSight offers five key features:

1. Requirements
2. Scoping
3. Development & Customization
4. Testing Impact
5. Risk Summary Cockpit

Watch it in action:

Always assess the risks associated with the changes you are making. This will help you follow the correct steps for deployment. You will be able to apply better judgment, especially when considering making changes straight away in your production org.

Frequently Asked Questions