It’s that time of year again with Salesforce getting ready to release their Winter 19 version. This post reviews the latest noteworthy features.
The Winter 19 release feels like a maintenance release with many of the new features being nice-to-have items or items that should’ve been there from the beginning. It’s nice that Salesforce is paying down some technical debt but I was hoping for some new meaty enhancements. For example, I heard rumors of a new Flow Cloud Designer on its way but that’s not in this release.
List View Search
Use the new search bar to search the field data in your list views and find the records you need in record time.
The list view search bar appears next to the List View Controls. The search bar works across all applicable fields for all the records in the list, even if specific columns aren’t visible.
I like the idea of searching through the records in a given list view but it feels unnecessary since there’s global search. Having two search fields also looks odd.
Bounce Back From Email Bounces
Sales Reps need to know when their emails to contacts, leads, and person accounts don’t go through. Without a warning they’re waiting for a response that won’t come. Now reps know which have a bad email address and which specific email wasn’t delivered.
This is nice that one can see the email is bad on a given record and is helpful. However, is there a way to report on all the records with bad emails? There doesn’t appear to be.
Let your sales reps see how their emails impact customers. In the activity timeline and the email detail record, reps can quickly see if an email isn’t being tracked or when a tracked email was last opened.
This applies in Lightning Experience in all the org editions
This is my favorite new feature so far and provides visibility to the reps. This makes me wonder if one can do additional analytics on this object such as number of emails Not Tracked, # of unopened emails, % of unopened emails, and others.
Set Component Visibility Based on Standard and Custom User Permissions
Now you can make your Lightning pages more dynamic by configuring component visibility filters based on the permissions of the person viewing the page. For example, you can create a rule for a component to display for users with a specific permission, but it’s hidden for everyone else. Component visibility filters are supported for standard components, custom components, and components from AppExchange.
Deploy Active Processes and Flows Using Change Sets or Metadata API
You can choose to deploy processes and flows as part of a continuous integration and continuous delivery model without manually activating them. Previously, processes and flows were always deployed as inactive. A new setting lets you deploy a new active version
of a process or flow via change sets or Metadata API.
Enabled using the new “Deploy processes and flows as active” setting. With this enabled, Active Process Builders and Active Autolaunched flows are subject to the 75% test code coverage and if it isn’t met, the deployment is rolled back.
Letting process builders and flows be deployed as active is a welcome addition that may save a lot of time. However, subjecting it to the test coverage limit will likely place another burden on many users and to those who don’t have the skill set to write apex test code. This feels like a nice idea in theory but the practical applications of it will have a large response from the community asking that this be removed.
Create and Edit Field Sets in Lightning Experience
It’s about time 🙂
Streamline API Calls To Your Org from Apex
Use the new System.Url.getOrgDomainUrl() method to interact with Salesforce REST and SOAP APIs in Apex code. Get endpoints for User Interface API calls, for creating and customizing picklist value sets and custom fields, and more. Use the updated System.UserInfo.getSessionId() method to retrieve session IDs, even when your code runs asynchronously.
Another it’s about time. This will definitely lessen the burden of calling an org’s APIs from Apex by removing the authentication step and having to store credentials.
Share Extensible Functionality with the Callable Interface
The System.Callable interface enables you to use a common interface to build loosely coupled integrations between Apex classes or triggers, even for code in separate packages. Agreeing upon a common interface enables developers from different companies
or different departments to build upon one another’s solutions. Implement this interface to enable the broader community, which might have different solutions than the ones you had in mind, to extend your code’s functionality.
I’ll have to research this further before determine if this is good or not. Initial impression is this seems unneeded.
Reference Custom Metadata Types in Advanced Formula FIelds
Create a custom metadata type, and reference its records in an advanced formula field. Store parameters for your formula in custom metadata types. If you need to make a change, you can do so in your custom metadata type instead of changing multiple, hard-coded formulas.
Instantiate Custom Metadata Types in Apex
One can now instantiate Custom Metadata Types in Apex but DML to them is still done through the Apex Metadata API. Another about time and will make test code easier to write.
Develop Against Any Org in Visual Studio Code (Beta)
This is a welcome edition since I’m still using the Force.com IDE. It’s unfortunate that’s it still in Beta and we have to wait until October 13, 2018 to use it.
Debug All Your Orgs For Free with Apex Replay Debugger (Salesforce Extensions For VS Code)
Apex Replay Debugger simulates a live debugging session using a debug log, which is a recording of all interactions in a transaction. You no longer need to parse through thousands of log lines manually. Instead, Apex Replay Debugger presents the logged information similarly to an interactive debugger, so you can debug your Apex code. With this release, we added checkpoints, which provide more information about your variables than debug logs do.
Sounds interesting and is on my R&D Backlog.