Summer 16 for Developers
Summer ‘16 features an expansion of limits (for a new set of editions). Limit expansions have been on the rise over the past three releases, and most recently we’re seeing a relaxation on sandbox limitations that may hinder environmental setups or scaling for large teams. Read on to learn about the coolest features and limit increases that Summer ‘16 offers developers!
Moarrr Sandboxes 2.0!
With the new “Lightning” editions and a slight price bump, some limits have also gotten a bump. The biggest win for developers is the increase in the number of developer sandboxes available for Professional, Enterprise, and Unlimited Editions. Enterprise Editions benefitted from having 25 developer sandboxes included in the Spring ‘16 release, but that wasn’t enough for developers. In Summer ‘16, developers receive 1 partial copy sandbox for Enterprise Edition orgs! No longer do developers need to maintain a set of Excel spreadsheets or execute Apex to create sample data when creating a new sandbox.
Clone Sandboxes
If you love cloning records or cloning users, you now can enjoy cloning sandboxes! This feature allows developers to create a new sandbox in production, but instead of cloning from the current production instance, developers are able to select another sandbox to use as the source of their clone! This can be a huge time saver if you have a large development team, or wish to create a separate environment for users to perform testing on a new feature.
Consolidating Asynchronous Limits
Prior to Summer ‘16, there were different limits based on the asynchronous action type, and there were 4 different ways to accomplish this! The two that I often use are @future methods and Database.executeBatch, and the limits were a bit of a drag, especially for the @future methods. Salesforce has wrapped all of these into a single asynchronous limit of 200 calls, which means that developers leveraging @future methods have a 4x increase to their existing limit!
Increasing Limits Across Namespaces
Salesforce has had a limit that previously allowed for only 10 namespaces of code to be invoked in a single transaction, which in effect means that only 10 managed packages would be allowed to execute during a single transaction. For orgs that have a lot of apps installed or have a robust app with many separate packages installed as features, this can produce a headache or even block the use of app offerings. This limit has now been removed (read: shifted) in favor of a scaling limit based on 11 times the number of per namespace limits. This means you could have more than 10 packages execute in a single transaction.
Do you have a favorite Summer ‘16 feature? Did we include it or miss it from our post? Let’s talk about it below in the comments, via Twitter @RogerMitchell, on our Facebook page, or in the Success Community!
