Published on November 3rd, 2015 | by Mike Gill0
Admin Commandment #2 – An Awesome Admin should always… use the sandbox for making changes (with a few exceptions!)
Here we go with our second Admin Commandment – an Awesome Admin should always use the sandbox, where available, for making and testing changes. Hopefully an obvious one, but you’d be surprised how tempting it is to go straight into production with something you might think is a ‘simple’ change.
Luckily for us Salesforce have made it incredibly easy to change and configure the platform, but with this great power comes great responsibility. The overwhelming ease with which you can rapidly make changes should be executed with caution. We are all App Builders to a degree now which is exciting, we totally get that. But simply diving into a live running system and building stuff, well that can be a little foolish. No builder of traditional apps would go straight onto the AppExchange or the AppStore with a product they haven’t fully tested. And let’s stop and think for a moment and ask ourselves one serious question – as a consumer of apps would you buy one if you knew it hadn’t been tested properly? So why would this be any different for Salesforce apps and for your users?
So what does this really mean, apart from the obvious ‘you must always test your changes before unleashing it to your users’? Rather than attack this from the side of things you should be doing in your Sandbox, let’s go at it from the other side – what things can and should you be managing directly in production?
Here are what we like to call Business-as-Usual activities, which can usually be done directly in production without an issue:
- User Management
- Reports and Dashboards
Wow that’s a pretty short list… And this means that the things you should be doing in your sandbox include (and this is not an exclusive list by any means):
- Apex and Visualforce
- Processes, Flows and Workflows
- Objects, Fields and Layouts
- Profiles, Roles and Security
- Custom Report Types
Let’s dive in quickly to each one:
Apex and Visualforce: This was a little trick one to see if you are actually awake. Correct, you cannot create Apex directly in Production, but you can sort of author Visualforce directly in production, but don’t do it. It is in the same bucket and should be treated exactly the same as core Apex.
Processes, Flows and Workflow Rules: The temptation here is massive, it’s like Salesforce did it on purpose to test out how strong your will is. Look it’s really easy to automate stuff, but think what automation means – things will be happening in the background that you can’t immediately see. So, seriously, how can anyone dream of automating something without testing? Let’s look at something more real, Process Builder is now bulkified with Winter 16, well almost. I think the wording they used is that your chances of hitting limits is reduced! So would it not be extremely prudent to test your process with the max number of records that your use case needs to support – makes sure that your requirement isn’t a second class citizen in the land of bulkification!
Objects, Fields and Layouts: I shouldn’t really need to say this, but unless you are on Professional Edition or lower creating fields directly in Production is an absolute no no! All these things are better designed and done in sandbox first. There are a few common pitfalls which admins fall into:
- Fields randomly appearing on page layouts for end users, well it’s not really random is it. It’s more the Admin forgot to uncheck add to layout in order to add the field to the page layout as an additional step after field creation!
- Changes are being implemented in Sandbox, except this time something urgent came up, so we decided to add the urgent field directly in production – net result: your Sandbox is not in sync with Production anymore!
Profiles and Security: How you view this one will largely depend on how strict your organisation is on security. Also how you have gone about implementing security in your org, e.g. the blend of Profiles versus Permission Sets. We knew this would be contentious, but let’s give you a decent real world example. Let’s say you have a Salesforce Community running with some custom objects containing personal information or something of that nature. Now imagine if a community user could suddenly see personal data for someone else – what would be the fall out of that? We are not trying to scare you, just to open your eyes. Nothing is more important to Salesforce than the data security of their customers, and in our opinion you should think the same and therefore ensure all security changes are tested in Sandbox first.
Custom Report Types: When mentioned earlier that creating reports in production is acceptable, so why are custom report types any different, especially when they can be listed as ‘in development’ prior to being deployed to all users? The primary reason in our opinion is that most reports tend to be built by admins, who see all report types whether they are in development or not, so having more than you need in production is only going to slow you down. The other reason is that in our experience it can take a few goes to get the exact configuration of objects correct in your report type, and sometimes you realise you don’t need a custom one after all. But who remembers to go back and delete the incorrect or unnecessary CRT you created? Not me, for one.
So we think the message is loud and clear now, if you have a Sandbox use it.
Apologies to those admins reading this who are currently on Professional Edition or lower and thus don’t have a sandbox to make use of. We sincerely hope this gives you another reason to be considering an upgrade to get that sandbox you and your best practice processes have always dreamt of!
Here are the Admin Commandments so far
#2 An awesome admin should always… use the sandbox for making changes (with a few exceptions!)
#3 Coming soon…