As I’ve just learned one minute ago, via Google, since I searched for it, primum non nocere is latin for “first, do no harm.” You might know this as a key part of the Hippocratic Oath – a pillar of medical ethics, the oath which every doctor might swear by.
As Salesforce administrators and developers, we don’t save lives, but we certainly can mitigate pain, and unfortunately, cause it. We have the power to facilitate and empower our users, or we have the power to make their lives needlessly complicated by rendering the tools they use each day opaque, inefficient, or just downright frustrating.
Usually, when any of the above are the case, it’s a question of improper or hasty testing, and a lack of discipline with regards to development best practices.
Though I’ve made many videos to date, I have yet to elaborate on my first ever post to this site, regarding pushing changes properly. Although that post was brief, it did mention that as administrators we must avoid at all costs to make changes directly to our production org wherever and whenever possible. So, today, in an effort to drive that point home, we discuss sandboxes: the different types, how to create and use them, and what do to when we’re ready to migrate a new feature into our production org.
On the next page, we’ll discuss the types of sandboxes and talk about which one you might want to employ.