Tune Up Your Salesforce Org with Every Release
Tune Up Your Salesforce Org with Every Release

Tune Up Your Salesforce Org with Every Release

03/19/2013 by Justin Edelstein
Salesforce is a living breathing application that changes three times every year. Here are some things you should check in your org with each new Salesforce release.

Salesforce has fallen into a nice, easy to follow, three release per year cycle. We know there is going to be a Summer release, a Winter release, and a Spring release. We also know the approximate timing of each of these releases based on the trends over the last few years. Ironically, The Summer release typically comes out at some point in the Spring, the Winter release comes out at some point in the Fall (generally around Dreamforce time), and the Spring release comes out toward the middle of the Winter. I think they do it this way so that it’s always looking forward but as we speak now in the middle of March 2013 we are all sitting in an org with the Spring 13 release even though we are still in the dead of Winter (at least we are here in NYC).

While part of the promise of Salesforce’s release cycle is that they won’t break anything, the truth is you should be paying attention to every release and how it may impact you. Sometimes features change in a way that could adversely affect your implementation. Here are some things to be on the look out for as Salesforce rolls out their new releases.

Critical Updates

Critical Updates come around every so often and are not turned on immediately, rather they are optionally turned on by an admin yet they automatically activate after a period of time. The most recent of these critical updates came with Spring 13 and was called Generate Correctly Escaped Markup. The most important thing to understand here is that this update is being made system wide and will be turned on at some pre-determined point called the auto-activation date. Salesforce is very good at reminding you that you should turn these critical updates on, or activating them, before the auto-activation date. They are also very good at describing what is being updated and where you would need to look for things that are impacted by this critical update. These updates don’t always impact everyone but Salesforce has taken the time to denote them as critical so they do warrant a few minutes analyzing how they may impact you and your org. Once you’ve analyzed how they will impact your org take the proper action to activate them (if they won’t impact your org negatively or at all) or fix/adjust to the update and then activate it.

Security Updates

Every time Salesforce adds updates to their security scheme this warrants extra special attention. Two specific recent releases come to mind as big ticket changes. The first being Permission Sets bursting onto the scene. While this is more of a passive change and an opt-in change, meaning you aren’t forced to use Permission Sets, they are extremely useful and could change the way that you would think about security in your org. This is part of the tune up process, seeing the new feature and deciding whether you can clean up some of the gunk from your org (proliferation of profiles) with a new feature.

The other security update that was recently rolled out was the change relating to sharing and portal users. This change rolled out in Summer 12 and it allowed orgs that utilized a portal to break out their org wide defaults for internal users and org wide defaults for portal users. This is extremely helpful when internally you want a very flat and open sharing model while users within the portal should only see certain records pertaining to their Account or only records that they own. Again, another tune up and cleanup area that allows for a simpler model for sharing. This feature won’t break anything that you currently have in place, it will however make an existing portal implementation and the security model around it much easier to manage.

Limits Limits and More Limits

As Salesforce is built on a multi-tenant architecture there are governor limits in place to make sure no single org is “hogging” all the resources from the shared infrastructure. These limits are in place for good reason and they are constantly changing and evolving, generally for the better. Over time limits for existing features seem to continue to either disappear or go “up” meaning allow for more and more customization. Very rarely does Salesforce take away an ability to do something by limiting you, they almost always go the other direction and give you more leeway though there have been times like when the recycle bin data retention policy went from thirty days to fifteen days where the reverse is true.

You should always be checking these limits with every release to make sure that you aren’t going to hit into any of them. As Salesforce rolls out new features with new limits and as they raise limits on existing features make sure your customization won’t be affected or perhaps could be modified or optimized.

Let me know about any other things that you do when a new release comes out. Would love to put together a neat checklist in the comments below so feel free to add to it. Also comment on our Facebook page or tweet with me directly @JustEdelstein.