Winter 16 for Developers
Winter '16 for Developers

Winter 16 for Developers

11/10/2015 by Roger Mitchell
Winter ‘16 has brought us Lightning with a ton of other features that developers can love. Here’s a recap of our favorites from the latest release.

Lightning Experience and many other features were dropped as part of Winter ‘16, and we’ll look into some of the features that developers will love with this latest release. A few of these features are iteratively built upon gems from the Summer ‘15 release, and others are brand new as part of this release. A quick note, this post does not feature anything about Lightning Experience, and purely focuses on platform enhancements.

Choose Test Options for Change Sets

Deployments are becoming easier for developers over the past few releases. Summer ‘15 brought the Quick Deploy functionality after a successful validation. Winter ‘16 allows for further fast-tracking with the ability to specify which tests run during validation or deployment. For larger organizations with lots of test classes, this can speed up a deployment to a minute, as opposed to waiting 30 minutes in larger, complex orgs to receive results. But be careful, this can potentially introduce logic to an org that can have nasty side effects.

Customize Trace Flags and Debug Levels in Setup

Debug logs are no longer capped at 20 instances for a given user. With Winter ‘16, developers are able to specify a time period over which debug logs should be collected. Salesforce sets a cap at how much data from these debug logs can be held. This is particularly helpful for troubleshooting scenarios that occur infrequently and are not easily reproducible, as well as for any API integrations that are leveraging the same user with high transactional volumes.

Trace flags and debug levels are also defined as “records”, so when defining a debug log, developers may tailor their logs to a per category. Developers often are aware of where a specific issue occurs, and by tailoring logging levels are able to get around the noise of irrelevant logging categories.

Declaratively Create Custom Metadata Types

Custom Metadata Types are an awesome feature from Summer ‘15 that allows developers to include and deploy data that supports the application. This is a nice change, as previously developers used Custom Settings and were required to load data to support their applications in each environment. A downside during the entire release period for Summer ‘15 was that the only way to create these records was via the Metadata API; this is not particularly helpful for developers that support administrators or wish to make quick changes during development. With the Winter ‘16 release, Custom Metadata Types are able to be created declaratively via the UI.

Named Credentials

Web Services integrations require an endpoint and authentication details. Prior to Winter ‘16, these could be defined as Custom Settings or within a Custom Metadata Type, though it didn’t make it particularly easy to manage these integrations. Named Credentials is the silver bullet for this, allowing developers to maintain their integration endpoints without the pain of managing these within Custom Settings.

Named Credentials are great for handling the single authentication use case, and are also helpful for per-user authentication. Users can define their own credentials, allowing for this data to be stored alongside the named credential, as opposed to storing the data in a Custom Setting or as fields on the User object.

Audit Fields and Inactive Owners

While these two features are paired together, there is a beneficial impact from the ability to update records with inactive owners. Handling these cases in code can be a bit frustrating, especially when the logic should succeed regardless of whether a record owner is active. Removing this constraint allows for getting around data issues that can result from process gaps with deactivating users.

Being able to set audit fields without creating a case with Salesforce is also helpful for migrations and integrations that require legacy or third party system data to have the appropriate creation and last modification dates and users. This is still only available when creating records via the API, but at least it is no longer restricted to a specific timeframe for longer term use cases.

Love one of these Winter ‘16 features, or have one that is left out? Feel free to comment below, in the Success Community, on our Facebook page, or via Twitter @RogerMitchell.