Yesterday was a big day in the land of Salesforce. The Salesforce Summer 2015 Release Notes were published, giving us 269 pages of new material to read through, analyze, and obsess over. And after 24 hours with them, here are 3 of the things in the Salesforce Summer 2015 Release Notes that I found to be most cool and that I think will improve the platform:
Finally, we can just use the Salesforce-provided Data Loader instead of having to use other tools. Now I don’t have to boot up my Windows machine just to use Data Loader. This is just plain cool.
At long last, you can update picklists with field updates. If you know the criteria for a field to be in a certain state, why force us to use triggers to set that state? It will be so nice to be able to set a picklist to a certain picklist option as part of a field update. Fewer needs in triggers is almost always a good thing.
Many times we, as developers, are uncertain about exactly what apex limits are being used during code running in production. We think we have a fairly good idea, but we’re never quite certain unless we build in logging code that tells us. This logging code can also affect the limits themselves depending upon how you do the logging. But now, this pilot program allows us to keep an eye on how all of the code in our Org is doing. We can see what runs are causing issues and what code is potentially using a lot more SOQL queries than we are expecting. More debugging information from Salesforce is a good thing, and I support these kinds of changes.
While going through the Salesforce Summer 2015 Release Notes, I also took another look at the Salesforce Spring ‘15 Release Notes and found a couple older things that I think deserve a little more attention. Here are 3 things from Spring ‘15 that deserve a second look.
This is excellent. Have you ever had a workflow or trigger not be able to update because it’s related to a user who is no longer with the company? Well, you’re not the only one. Users have complained countless times because of a somewhat ugly error code popping up when they do something that affects another object that they can’t edit. Now that should be a problem of the past.
This helps limit the amount of code duplication that you have in unit tests. Since most unit tests within a class deal with roughly the same data, this makes it much easier to set up data the same way for each unit test and just make modifications that apply to the specific unit test you are working on. Amazingly good idea.
This is just the tip of the iceberg in terms of the biggest and best highlights of the new Salesforce Summer 2015 Release Notes. Keep an eye on our blog for lots more news from others at Red Argyle as they delve in the document over the next few weeks.