• Lauren O'Brien

Learning to Love the Salesforce Sandbox

This might sound like blasphemy to some, but, for quite some time in my Salesforce career I barely ever touched a Salesforce Sandbox. Shocking, I know, but I tended to work for smaller companies where most changes had little to no chance of affecting other data points, or processes, so working in the Sandbox and then porting over to Production just sounded like unneeded, additional work and I had plenty of open tickets keeping me busy so why not just create, test, and deploy right in Production!?

It took many a years, and while I do still create directly in Production from time to time, but I learned to the love Salesforce's Sandboxes and much of that is tied directly into new declarative tools Salesforce has provided to us in the last few years, primarily Process Builder and Flow.

If you are not familiar with Process Builder and/or Flows, first - stop, drop, and learn. Both put a lot of power into the hand of Salesforce Admins without the need to write Apex so Admins can use these declarative tools to update related objects, create objects, delete objects, sending notifications, and so much more but with great power comes great responsibility which is why a Sandbox is crucial.

(Should probably take a few moments to explain what a Salesforce Sandbox is for those unfamiliar. In short, there are several types of Sandboxes but they all provide an environment where you can build and test without the risk of affecting anything in your Production.)

So, let's imagine you are trying to build a Flow for the first time and this Flow is supposed to delete a set of records pending they meet certain criteria. If you build directly in Production, and even build correctly, when you go to test you will actually delete records in your Production which could be disastrous (though a little less so now that the Recycling Bin is coming to Lightning in the next release) but if you build within a Sandbox then you can build, test, and delete to your heart's content without worrying about losing critical data that is actively been used and/or reported on in Production.

Relying on a Sandbox can also allow you to be more bold when creating something like a Process Builder because if you fall short, or do not experience the intended outcome, there are no lasting affects so you can try going outside the lines which may end up producing some amazing results, and if not, no harm, no foul in the Sandbox! Using a Sandbox to create Flows for the first time really expanded my thoughts on their capabilities and am now implementing Flows I did not know were even possible just a few months ago.

Another reason for my shift in appreciation is due to Change Sets. There are some limitations to Change Sets but overall they allow you to send customizations from one Salesforce Org to another so if you build something in the Sandbox, with a few clicks you can send it over to your Production without having to completely rebuild from the ground up which means a lot of time saved which is so important to the ever-busy Salesforce Admin.

As a short recap, using a Sandbox can be a little annoying sometimes, and may add some additional time to a task, but take advantage of an environment where you can test without fear and expand your skills and confidence without needing to worry about consequences on Production.

Don't currently have a Sandbox? You can sign up for a Developer Edition for free.

13 views0 comments