Salesforce Sandbox – Managing Changes in Production

Salesforce Sandbox Changes

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 RequestEnvironmentConsiderations
I need a new picklist value for a custom picklist on our accounts.LiveData 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.SandboxYou should test any workflows or process builders before live deployment.
I need to create a new standard product.LiveDon’t forget to set the price books up for the new product.
I use CPQ and need to create a new product.SandboxCPQ 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.SandboxApproval 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.LiveIt’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.LiveDashboard 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.LiveCreating 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

What Is a Salesforce Sandbox?

Sandboxes create copies of your Salesforce org in separate environments. You can use them for development, testing, and training, without compromising the data and applications in your production org. Salesforce offers sandboxes and a set of deployment tools, so you can:

•Isolate customization and development work from your production environment until you’re ready to deploy changes.

•Test changes against copies of your production data and users.

•Provide a training environment.

•Coordinate individual changes into one deployment to production.

Why Should I Test in a Salesforce Sandbox?

Salesforce allows you to try out new ideas, customize applications, and develop your solutions without impacting your customers’ data. It is essential to test in a sandbox environment so that:

·       You can integrate updates into development projects at any stage rather than waiting until they are complete to deploy them in a production org.

·       A sandbox environment accurately reflects a Production environment, so testing against a sandbox in Salesforce can help identify issues associated with integrations that will not affect your customers’ data. 

·       Sandbox helps you test old or outdated versions of live objects. Testing in a sandbox for Salesforce tests your custom code and ensures that there is no impact on the data, and you can upgrade to the latest released version smoothly.

What is the size limit for the Salesforce sandbox?

Salesforce is continually evolving, so this is prone to change, but the size limit for a Salesforce sandbox depends on the sandbox types you’re referring to:
Developer Sandbox: A copy of your organization’s configuration (metadata) without the production org’s data. Limited to 200 MB.
Developer Pro Sandbox: Like the Developer Sandbox but with a larger storage limit. Limited to 1 GB.
Partial Data Sandbox: A Developer Sandbox with a sample of your organization’s data. Limited to 5 GB or a maximum of 10,000 records for most standard objects.
Full Sandbox: An exact copy of your production environment, including all data, such as object records and attachments. Size is the same as the production org.

Want To Learn More About Panaya ForeSight?

We’re Hiring!

Apply now on our Career Center or via Linkedin

Start changing with confidence

Book a demo
Skip to content