Nexell Blog - Customer Relationship Management, Technologies and Methods


Welcome to our constantly changing world of CRM, and technology news, expert articles, updates, reviews & opinions.

"Up or Downdate - Get control of your sandboxes"

Author: Steeve Seidel - Nexell Senior Consultant.

Sandboxes with toys in sand

I love playing with single-board computers, Raspberry, Arduino, ESP32. Reverse-engineering is complex and exciting. However, you need a lot of tries before you get anything to work. For example, as I started with my home-automation, I bought a domotic box. The beginning was nice and interesting but soon I could not do the scripts I wanted. I could not make a backup or restore anything if I had a problem, and if I did not have an internet connection, nothing worked (which was not really great for home automation). 

Then I started to install software on Raspberry (a small single-board computer). I spent a lot of time before it worked as I wanted it to. Then, when everything worked fine, I tried to follow the update process, updating the operating system and the software itself. The updates were fast and worked perfectly until one update broke my system. Yes, I had a backup and yes, I could restore it (partially) but I lost a lot of time. 
Despite this fact, you now know what a Raspberry is—but what is the point of this story?

Update "à la" Salesforce
In the Salesforce world, we do not have the choice to deploy an update or not. The updates are coming (3 times a year for Salesforce and more for an NPSP org). If you have other apps on your org, you will probably also get regular updates for them as well. We need to understand the changes and new features, if they are "impacting" the systems, their dependencies, etc. Many updates are generating many questions—the biggest one being how best to handle this.

Let me ask you some questions:
  • How many sandboxes do you have?
  • What types of sandboxes do you have?
  • When were your sandboxes last refreshed?
  • How often can you refresh your sandboxes?
  • On which instance are your sandboxes?
  • On which sandbox do you have all the apps installed?
  • On which sandbox do you have real data?
  • On which sandbox do you have data?
 If you can answer all these questions, please stop reading. You are the best!
Sandbox and Strategy
First, if you want to manage this, you need a strategy. You do not need to include all your sandboxes in your strategy; rather, you need to include your most important sandboxes. The question is: Which sandboxes are important? How many do I need? More questions and more answers are needed.

To be clear, there is not one single strategy that is suitable for all systems. You will need a sandbox with almost the same status as your production environment, where you can test the integration of all apps, where all your sandboxes will converge. How many more sandboxes you need depends on how complex your system is. 

You do not need a development sandbox if you are not writing any code, but you do need a sandbox to create and test your process builders or workflows. The more sandboxes you have, the more complex your strategy will be because you will need to align your sandboxes with the Salesforce release cycles. You could face issues if you try to deploy some code from a Summer-release sandbox to a Spring-release Production-Org. You must know how and when to refresh your sandbox to be sure that you will have the right release in the right org and at the right time.
Strategy and Testing
Ah! Fine... I have my sandbox in the right release. All the apps are running in the new releases and some data is inside. 

Now comes the question: What do you want to test? How do you want to test? Or do you really need to test? At least all the apps are now inside the new release and they seem to work. Or do you just want to run a test to see if everything is running fine? Do you want to do a mass update? Again, this depends on your org and how you use it. 

If you have API-Callouts, you will need to test to ensure that they are running smoothly, as the API could have changed. You will need to test if Email2Case or Web2case is still running. You will need to test your Payment-Portal to be sure that the payment will still come in. Yes, if you are doing your tests seriously, it will take some time. But this is the guarantee that you will not miss anything when the release is uploaded to your productive system. 

When I am doing tests, I too often test “positive”. This means I test if the normal use-case is working. This is good, but what about the “negative” testing? If you try to update a case where there is no value or a wrong value, will your process also work? Did you try to test your Process builder with another Record Type or with an unexpected value? Do it; it is important.
Think “Upside-Down” to test the improbable use-cases. I can assure you that your users will find completely unexpected scenarios!
And now?
Let’s talk seriously... What can you do to prepare for the coming updates (all of them)?
  • READ what's new and the release notes (it’s a lot of reading, I know, but it’s better to read too much than to come into the office one morning and find issues in your system).
  • CONCENTRATE on the points that can affect your processes (no need to study all Marketing Cloud details if you use only Service Cloud).
  • START EARLY with your planning and strategy (one month before is not enough, as your full sandbox can be refreshed only every 29 days).
  • Discuss and PREPARE your colleagues so that they are aware of the changes (do not forget to also inform your users, as some updates are really exciting and have a major impact).
And if it is all too much?
Just call us. We will help - for sure 😊
Prevent And Manage Duplicates in Salesforce
Data Sharing: Calm River Or Troubled Water?

By accepting you will be accessing a service provided by a third-party external to

Subscribe to our Newsletter

You will receive regular information about our events, expert articles, the latest success stories, news about our NexellAngels initiative and much more.