Managing Salesforce Sandbox Changes in Production

by | October 28, 2018


Managing Salesforce Sandbox Changes in Production

Every organization using Salesforce has a production or “live” org and a set of sandboxes. The production org is actively being used and has live data, whereas Salesforce Sandboxes are replicas of the production org and don’t contain any live data or active users.


This makes the sandbox a really useful and risk-free place to make changes and test them, without it affecting anything else. The sandbox has all the same tools, functionality, and setup as your live org (if you’ve refreshed it recently), so you can use it to make changes knowing that any effects those changes have will have the same effect in live.


How to Clean Your Salesforce Org in 6 Steps


But there may be times when you think that doing work in sandbox and then having to deploy it to live is just too long-winded. This can be true in some cases, some not. It’s important to know exactly when changes can be made in live; you also need to take the right measures to do them properly.

Changes in Production, Why Not?

There are about a hundred new metric requests coming from the directors, bugs from the customer service department, and changes required by the sales team. Sound familiar?


Sometimes it might just feel a lot quicker and easier to go ahead and make the needed changes in your company’s live org. But have you or the requester considered who or what else might get impacted by those changes?


There are often knock-on effects when changing things in Salesforce; for example, validation rules may block a workflow you’ve made, or a field you are trying to remove is actively being used by somebody else. You need to make sure you’ve assessed all the effects any planned changes will have on your system before performing them.



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



A Process of Elimination

First, you should address what is involved in the change. Can it be achieved purely with configuration, or does it require code? If the change does require coding, then you have to do it in a sandbox anyway, as you cannot write code directly into a production org in Salesforce.


As for any configuration changes, anything that uses automation tools should be tested first. Again, these changes are better made in a sandbox environment, where any automation won’t affect live data. When removing anything, it is always preferable to use sandboxes as well to prevent loss of data. You’ll find that removing things (especially fields) is harder than it would seem, as they are often referenced in workflows or code.


How to Clean Your Salesforce Org in 6 Steps


That leaves you with creating new things in config. Some of the bigger impact changes are best done in sandbox and rolled out, such as new objects, record types, and page layouts.

However, there are quite a lot of new config you can do without it affecting others or the data in your system, for example, new fields, picklist values, reports, email templates, profiles, or roles. This is provided you still take precautionary steps before you go ahead with them.

Do It Right

So, if you have decided that you can make the changes in the production org, there are some really simple steps you can take to make sure there is great adoption and no negative impact!


  • Double check – Make sure what you’re doing isn’t going to have any direct or indirect impact on anything or anyone that it’s not supposed to.


  • Communicate – Always make certain your changes are communicated to your team before you make them. This makes sure nobody is going to be surprised by your changes or use them for another purpose.


  • Phase release – It’s always best to get other admins, superusers, or the change requester to check your new change before you release it to everyone. This will confirm if it is fit for the intended purpose or will allow you to make adjustments before the wider team uses it.


  • Training – Whether it be a short how-to guide or a live training session, training is vital to getting your users on board with your change. It will give you the opportunity to explain what the change is and how best to use it.


What Changes to Make in Live vs Salesforce Sandbox

Below is a list with a variety of common day-to-day change requests you may get and in which environment you should be making them.


Change Request



I need a new picklist value for a custom picklist on our accounts.


Picklists that are used for simple data entry purposes tend to have little impact on other things, especially when adding new values.

We have added a new step in our sales process, so we need a new picklist value for opportunity stages.


As this feature will likely be used globally across the business, it needs careful assessment before being changed.

I want a new custom text field on Leads to capture more details.


As well as the steps outlined above, make sure you check that lead mapping is set up for this field.

We need an email alert to be sent to customers.


You don’t want emails being sent to the wrong people or with the wrong content.

I’d like a field to automatically update when an opportunity is closed.


Any workflows or process builders should be tested before being deployed to live.

I need a new standard product to be created.


Don’t forget to set the price books up for the new product.

I use CPQ and need a new product to be created.


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, which can then be connected to many different rules.

I want an approval process to be made for discounts on opportunities.


Approval processes are like workflows; they have impacts on 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.


It’s worth checking whether this is a specific user’s case or all other users with the same profile require this permission. It can be the difference between a permission set or a profile change.

I would like to add a new component to a dashboard.


Dashboard components are sourced from reports, so you would have to create the report first. A good way to make and change reports and dashboards is to do them in a private folder and then move them to a public folder.

I need to add fields to a page layout for a specific profile.


When you create a field it will give you the choice to add to any page layout, but 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
Top 10 Salesforce Features of Winter ’19



In Summary

Ultimately the best way to reduce risks resulting from any changes is to do everything in a sandbox, then test and deploy to production. However whether you’re delivering this way or making changes straight to production, it’s good to utilize a change management tool like Panaya’s Release Dynamix for Salesforce. It will deliver the data you need to show you any elements that will be affected by changes you’re looking to make as well as the resulting impact on those elements. This product is a critically useful tool when trying to assess whether the changes should be done in live or not and enables you to eliminate guesswork—and risks—before going into production via five key features: Requirements Scoping, Development & Customization, Testing Impact, Risk Summary, and Risk Cockpit. 


By assessing the risks, fully understanding what changes you are making, and following the correct steps for deployment, you will be able to use better judgment when considering performing changes straight away in your production org as well.


How to Clean Your Salesforce Org in 6 Steps