Summer is officially here. The sun has his hat on, the Pimms is flowing and the BBQs are firing up! Also just like each Summer, Salesforce is making one of its three annual releases. In Summer '14, we see the introduction of extensions to user permissions, a massive increase in API calls, and the ability to handle much larger files as attachments on Objects and e-mails.
The training material for Force.com (for those looking to pass their maintainence exam or find out more about the release) is pretty quick, lasting just a shade over two and half minutes. Viewing this alone, you may be tricked into thinking the only change of note is to user access permissions.
What I want to do in this blog post is dig deeper, way down into the release notes, and demonstrate the not so well known features that are going to be introduced as part of this latest release, that make things possible on the platform for the first time, and can alleviate previous restrictions. I have also included a few new features that you need to be aware of that may impact your org in the future.
So without further ado, here are my 7 need to know features in Summer '14 release:
1) Light vs. Enterprise Objects
As part of Summer '14, when you create any new objects, you will be asked as part of the initial configuration, a series of questions about the your new object:
Allow Sharing (checkbox)
Allow Bulk API Access (checkbox)
Allow Streaming API Access (checkbox)
These settings are all or nothing. If all of the objects are selected, your object will be classified as an "Enterprise" object, if you uncheck all, it will be classified as a "Light" Object. All objects created prior to Summer '14 will be classed as "Enterprise" objects.
So ok that's nice, but why is that relevant you ask? Why would you ever choose a "Light" Object? (apart from if have very selfish users :-D ) . Well this actually all comes down to Licence arrangements for your org. Since Spring '13, The Force.com light licences have been available. There isn't much information about these licences out there, but thankfully
Shell Black has a great post explaining licenses.
Basically, if in your org certain users cannot see types of custom object, checking if it is a "Light" object is probably a very good place to start.
2) Increased Maximum Length for Long Text and Rich Text Fields
Long text fields can now be edited to be four times as big in size, 128KB rather than 32KB (or 131,072 rather than 32768 characters). A small change but will free up some implementation concerns, so now your users can ramble to your hearts content!
3) Increased Maximum Number of Relationship and External ID Fields Available Per Object
The number of relationships (lookups/master-details etc.) per object has been increased from 25 to 40, particularly useful if you have complex data models (though in all honesty if you do need all 40 relationship fields, you may want to review your data model!).
Also, the number of fields that can be labelled as External Ids, useful for uploading records from other connected systems with their own unique referencing models, has been increased from 3 to 7, so its now even easier to upsert your existing system data.
4) Full File Search Now Available in the Developer Console
For me, one of the benefits of using an external IDE over the developer console has been the ability to quickly identify search your entire codebase for a particular tag or method, using a complete file term search. An example is when you have a question like"I'm sure I've used the apex:ActionFunction in this project before, but where?". With Summer '14, a complete file search function has been added. Simply go to Edit > Search in Files in the menu, or use the keyboard shortcut (CTRL + shift + H) to open the dialog, and then enter your search term.
There are currently some usability limitations, for example you cannot use a search term that contains a ":" character (like when searching for an apex tag), and there are only so many results that can be returned in the panel. Despite this, I think this still a really good addition to the developer console.
5) Remote Object Enhancements (Developer Preview)
In Spring '14, a new method of interacting with objects via Javascript was introduced in the form of Remote Objects. Using Remote Objects allows you to modify the data in your org purely at the view level using Visualforce alone, you do not have to define any logic in Apex classes. You can read more about Remote objects in this
Remote Objects blog post by Josh Birk
The Summer '14 release extends this new feature further, with the addition of an upsert command to update or insert objects based on if they already exist (just like with SOQL). You can now also order your results on the page using an orderby command, use geo-location fields, and use more complex query conditions (not equal, less than or equals, greater than or equals). These enhancements will make it even easier to replace large chunks of Apex code with lightweight Javascript. Give it a go if you haven't done so already!
6)
Unlimited Describe Calls
Describe calls are used in Apex to dynamically access the data model configuration of your org. You can use describe calls, for example, to view the possible values of Picklist fields, or even get all of the fields that belong to an object. I have used these methods successfully in previous posts, especially those regarding cloning objects.
Previously Describe API calls have been limited to 100 per code execution process. In summer '14 this limit has been completely removed, so you can make as many calls as required. A couple of words of warning though, remember that this limit was there originally for a reason, if you are running code that is using the describe method over 100 times, you may want to consider if there is not a more efficient way to get the information you need. Don't get slack in your coding just because the limit is gone :D.
7) Create Price Book Entries in Tests
This is a win for anyone (including myself) who has ever had to create a test relating to price book and price book entries. Before this release, the only way to access a price book to create entries was through the use of the *evil* seeAllData=true flag in your tests. Now, thanks to the new Test.getStandardPricebookId() method, you can access a price book and associate new Price Book Entries without having to access all data.
Here is an example of the method in use, taken from the Summer '14 Release Notes:
@isTest
public class PriceBookTest {
// Utility method that can be called by Apex tests to
// create price book entries.
static testmethod void addPricebookEntries() {
// First, set up test price book entries.
// Insert a test product.
Product2 prod = new Product2(Name = 'Laptop X200', Family = 'Hardware');
insert prod;
// Get standard price book ID.
// This is available irrespective of the state of SeeAllData.
Id pricebookId = Test.getStandardPricebookId();
// 1. Insert a price book entry for the standard price book.
// Standard price book entries require the standard price
// book ID we got earlier.
PricebookEntry standardPrice = new PricebookEntry(
Pricebook2Id = pricebookId, Product2Id = prod.Id,
UnitPrice = 10000, IsActive = true);
insert standardPrice;
// Create a custom price book
Pricebook2 customPB = new Pricebook2(Name='Custom Pricebook',
isActive=true);
insert customPB;
// 2. Insert a price book entry with a custom price.
PricebookEntry customPrice = new PricebookEntry(
Pricebook2Id = customPB.Id, Product2Id = prod.Id,
UnitPrice = 12000, IsActive = true);
insert customPrice;
// Next, perform some tests with your test price book entries.
}
}
