"Is it OK to refresh the Partial?" is a question that I regularly hear. Unfortunately I also have to ask it myself sometimes. There is a good way to make this question redundant and never risk losing unpublished work.

Maybe it's good to give you a little explanation about the above. Perhaps you read a few terms that are new to you. I will explain those because the lesson I want to convey in this article is a very valuable one for yourself, but also for everyone with whom you collaborate on the configuration of your environment.

What is a Sandbox?

If you want to add new functionality or just want to try out something you have learned, do so in a sandbox environment. This is a copy of your production environment where you can experiment without accidentally breaking functionality or messing up real data your company relies on. A sandbox is pretty much what it says on the sign: a safe playground.

There are basically two types of sandboxes

Developer Sandbox

A developer Sandbox only contains all the metadata of your production environment (fields, page layouts, flows, approval processes, etc.), but no data (such as customers, contacts, cases, or contracts). To test or demonstrate something, you will still need to create data in that Sandbox yourself. With Enterprise Edition - which I see used most often - you can have up to 25 developer Sandboxes active at the same time.

Partial Sandbox

A Partial Sandbox contains not only all the metadata but also a part of the data of the production environment. This is a convenient environment for extensive testing of new functionalities. With Enterprise Edition, you can have 1 Partial Sandbox active at a time.

Creating or refreshing a Partial Sandbox takes longer than creating a Developer Sandbox and may be done less frequently.

What does it mean to refresh a Sandbox?

When you create or refresh a Sandbox, you take a snapshot. Your Sandbox is then, in terms of configuration and metadata, identical to your production environment.

Over time, a Sandbox can fall out of sync with the production environment. For example, if changes have been made directly in the Production environment. If this is the case, you cannot blindly trust the tests you do in the Partial Sandbox and you may even run the risk of unintentionally overwriting functionalities in the production environment.

If you suspect or know that your Partial Sandbox and Production environment are not in sync, you should refresh the Sandbox - take a new snapshot. If you work on this with multiple people, refreshing could also remove someone else's work in progress. That is why you want to coordinate this with your fellow admin(s) and consultants and developers of your technical partner. In this article, I will explain a method for managing the Partial Sandbox so neatly that you actually never have to refresh it. At least not because the metadata is out of sync.

Managing Sandboxes

You can create, refresh, and delete Sandboxes via Setup > Sandboxes

Build and Test using a consistent routine

Keeping your Partial Sandbox as accurately matching your production environment as possible in terms of metadata/configuration is invalueable. This makes refreshing unnecessary. Every time you refresh a Sandbox, there is a potential risk of losing newly built features that are not yet deployed to the production environment.

Therefore, it is a good habit to develop new functionality in a Developer Sandbox. Then publish it to the Partial environment for testing by means of change sets. If the Partial Sandbox is refreshed before you went live, you still have a backup and can use the previously used change set in your Developer Sandbox to republish the functionality to the Partial Sandbox.

By working strictly in a Developer Sandbox, you can first perfect your work there before polluting the Partial Sandbox with outdated Flow versions or fields that you later find you don't need anymore.

And if everyone neatly publishes everything that goes to Production to the Partial, the latter remains a reliable and up-to-date copy of the Production environment.

A good back up

During testing or even during production use, you will undoubtedly be tempted to make a small change immediately in the Partial or Production environment. Get used to consistently making even the smallest changes in the Developer Sandbox and publishing from there. This way, the Developer Sandbox is always a reliable, complete, and up-to-date backup of your functionality.

The diagram below shows exactly what this process looks like.

When the functionality is fully live, it can be good to delete the Developer Sandbox in which you built the functionality. Do this immediately when you are sure that all the functionality that was created there is also safely secured in another environment (Production). Otherwise, you may end up with a whole series of Developer Sandboxes that you are afraid to delete because there might still be something important in them, but what was it again…

Changes Sets

Change sets are the way to exchange most types of metadata changes between related environments. There is much to say about change sets, but that will be for another article.