Salesforce

Salesforce Sandbox: Managing Changes in Production

by | October 28, 2018

,

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 is a useful environment for making changes and testing them. In sandbox, your changes will not affect any live business processes. The sandbox has all the same tools, functionality, and set up as your live org (if you’ve refreshed it recently). You can, therefore, utilize it to make changes. Be aware, though, that any effects those changes have in sandbox, will manifest itself in live.

 

There may be times, However, when you think that working in sandbox is too cumbersome. It does not eliminate the need to deploy your work to live. Are you contemplating making those changes in live? It’s important to know exactly when it is okay to make changes in live. You also need to take the right measures to make those changes properly.

 

 

How to Clean Your Salesforce Org in 6 Steps

 

 

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 own 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 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 need to make sure 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 sandbox environment. There, automation will not affect live data. When removing an element, it is always preferable to employ sandboxes to prevent loss of data. You’ll find that removing things (especially fields) is harder than it would seem. Missing elements are often referenced in workflows or code.

 

That leaves you with creating new things in configuration. Some of the higher impact changes are best done in sandbox and rolled out. For example, new objects, record types, and page layouts.

 

Nevertheless, there is quite a lot of new configuration that’s doable. It causes no consequence to others or loss of data. For example, new fields, picklist values, reports, email templates, profiles, or role. Remember though, to take precautionary steps before going ahead with them.

 

 

How to Clean Your Salesforce Org in 6 Steps

 

 

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

  • 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 others 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 help to confirm your change is fit for the intended purpose. Otherwise, it will allow you to make adjustments before the wider team uses it.
  • Training. Whether it is a short ‘how-to’ guide or a live training session, training is vital. It helps in getting users on board with your change. Training renders you the opportunity to explain what the change is and how best to apply it.

 

———-

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

———-

 

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 receive. Use this list to learn in which environment you should be making them.


  • Change Request: I need a new picklist value for a custom picklist on our accounts.
  • Environment: Live
  • Considerations: Data entry picklists usually have little impact on other things. especially when adding new value.

  • Change Request: We have added a new step in our sales process. Now we need a new picklist value for opportunity stages. 
  • Environment: Sandbox 
  • Considerations: As this feature will likely be used globally.  it needs careful consideration before being changed across the business.

  • Change Request: I want a new custom text field on Leads to capture more details. 
  • Environment: Live 
  • Considerations: Make sure you check that lead mapping is set up for this field.

  • Change Request:  We need to send an email alert to customers.
  • Environment: Sandbox  
  • Considerations: You don’t want to send emails to the wrong people or with the wrong content.

  • Change Request: Whenever a salesperson closes an opportunity, I’d like to automatically update the relevant field.
  • Environment: Sandbox
  • Considerations: You should test any workflows or process builders before live deployment.

  • Change Request:  I need to create a new standard product.
  • Environment: Live
  • Considerations: Don’t forget to set the price books up for the new product.

  • Change Request:  I use CPQ and need to create a new product.
  • Environment: Sandbox
  • Considerations: 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.

  • Change Request: I would like to create an approval process for discounts on opportunities.
  • Environment: Sandbox
  • Considerations: Approval processes are like workflows. They impact multiple users and records and will often require a lot of testing to get right.

  • Change Request: I need permission to make changes to a particular field.
  • Environment: Live
  • Considerations: 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.

  • Change Request: I would like to add a new component to a dashboard.
  • Environment: Live
  • Considerations: Dashboard components are sourced from reports. Therefore, you would have to create the report first. A good way to make and change reports and dashboards is in a private folder. Once created, move them to a public folder.

  • Change Request: I need to add fields to a page layout for a specific profile.
  • Environment: Live
  •  Considerations: When you create a field it will give you the 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
Top 10 Salesforce Features of Winter ’19

———-

 

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 your changes straight to production. For example, check out Panaya Release Dynamix (RDx) for Salesforce.

 

Panaya RDx delivers the data you need. It shows you the effect on any elements as a result of the changes you’re looking to make.

 

RDx is a useful tool when trying to assess whether to make certain changes in live or not. It enables you to end guesswork—and risks—before going into production.

 

RDx offers five key features:

 

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

 

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.

 

 

Continuous Delivery for Enterprise Applications