Salesforce Sandbox Changes

Salesforce Sandbox – Managing Changes in Production

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.

Your copy sandbox salesforce is a helpful environment for making and testing changes. The sandbox has the same tools and functionality and is set up as your live org (if you’ve refreshed it recently). You can, therefore, utilize it to make changes. However, be aware that any effects those changes have in the sandbox will manifest themselves in the live environment.

There may be times when you think that working in the sandbox is too burdensome. It does not eliminate the need to deploy your work to live. Are you contemplating making those changes in live? Knowing precisely when it is okay to make changes live is essential. It would be best if you also took the right measures to make those changes properly.

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

First, you should address whatever the change entails. Can you achieve it with configuration, or does it require coding? If the change does require code, you must use a sandbox. You cannot write code directly into a production org in Salesforce.

As for configuration changes, test anything that uses automation tools first. These changes are better made in a Salesforce sandbox environment. There, automation will not affect live data. When removing an element, it is always preferable to employ sandboxes to prevent data loss. You’ll find that eliminating things (especially fields) is more complicated than it would seem. Missing elements are often referenced in workflows or code.

That leaves you with creating new issues in configuration. Some higher impact changes are best done in sandbox and rolled out—for example, new objects, record types, and page layouts. Nevertheless, there are quite a lot of new configurations that are doable. It causes no consequence to others or loss of data—for example, new fields, picklist values, reports, email templates, profiles, or roles. Remember, though, to take precautionary steps before going ahead with them.

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.

  • 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. 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.

What Changes to Make in Live vs Salesforce Sandbox

Below is a list of a variety of common day-to-day change requests you may receive. Use this list to learn in which salesforce sandbox environment you should be making them.

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


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:

  • Requirements
  • Scoping
  • Development & Customization
  • Testing Impact
  • 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 are the different types of Sandboxes in Salesforce?

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

Developer Pro Sandbox
A Developer Pro sandbox is 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.

Want To Learn More About Panaya ForeSight?

We’re Hiring!

Apply now on our Career Center or via Linkedin