Spring 19 is upon us and there are a lot of great features in this release! Here are some of the top features that I’m excited about.
Salesforce will start to turn on Lightning Experience on a rolling basis starting in Winter ’20. If you’re not on Lightning yet, make sure to start your transition planning to be ready for Winter ’20 (currently expected October 12 per trust.salesforce.com maintenance for NA59).
This has to be one of my favorite things that is coming out and it is a critical update. What does it do? I think an example helps. Let’s say that you sell things with a partner channel and have a lookup field on an Opportunity to lookup an Account to set the Partner on the Opportunity. When an Opportunity is Closed Won, if the Partner type is Gold, then you want to do one thing, and if the Partner type is Silver, do something else. Everything works fine UNLESS there is no Partner listed on the Opportunity. If there is no Partner listed on the Opportunity, then the Process Builder will give you an unhandled exception error. This is because it is trying to lookup a field on an Account that doesn’t exist. With this critical update, instead of creating an error, it will process everything as if it were null, so it would do neither the Silver or the Gold action, however it will not fail. This allows Process Builders to be built with less information. Previously, in order to not allow this to fail, you would have had to first check if the Partner field was null and then check the value, in that specific order. If you didn’t check for null first and the lookup field was null, that is when you would get the error. So this will help to reduce the amount of configuration needed for a Process Builder and will reduce the number of errors that a Process Builder might throw.
If you have created a Lightning Page and selected a layout, but want to change it, you now can!
This sounds really interesting for Omni-Channel orgs. You can now use the fields of incoming records to assign work to agents. This should allow more flexibility in routing cases to agents and more customization based on the unique needs of each case.
Currently, all sandbox emails change from their email to an @example email. An example of this is email@example.com turns into firstname.lastname@example.org. Moving forward, emails in sandboxes will change to add .invalid to the main email, so using the same example, the new format is is email@example.com. Although this is a small change, users unfamiliar with the old pattern could get confused easily, so this should help make sandbox emails more straightforward.
Lightning Experience has many benefits for users regarding the user experience. One of the highly requested features was, when clicking on an object tab, to be able to select the list view that you would like to see. With Spring 19, this is now possible! Previously, every time someone clicked on an object tab, like Opportunities, it would default to recently viewed. Now each user can “pin” the list view that they would like to have defaulted, helping to improve the user experience and reduce the number of clicks it takes to get to where the user is trying to navigate to.
This is a highly requested feature on the idea exchange. The Accept work button was available in classic, but not lightning, at least not until Spring 19!
Navigation Updated for Small Screens
I can’t find this in the release notes, so I hope it is actually going to be updated when production gets updated, but in the pre-release orgs and sandboxes the navigation for “smaller” sized screens now shows the full menu instead of getting cut off. Notice on the screens shots below, the navigation bar adjusts correctly for the screen size, but the items in the same row as the search bar do not.
Log Emails to People Who Aren’t Email Recipients from Gmail™
Log Emails to People Who Aren’t Email Recipients from Outlook®
Now you can relate an email to a Contact, Lead, or Person Account that is not part of the email. This is helpful when someone has multiple emails and you have a single Contact record for them, you can still relate their email to their Contact record. In addition, if someone replies but forgets to reply all, you can still relate the email to people who might have been left off the email.
This one makes SOQL queries very nice for Lightning Development. With SOQL, you used to be able to see if a user could see a record based on with sharing. While this was nice, if you’re creating a table using fields in a field set, a user might not have access to certain fields in a field set. So after getting the records the user could see, a developer would also have to ensure the user could see each field. Using the new WITH SECURITY_ENFORCED as part of a SOQL query, developers can save time knowing if a user is allowed to see a field or not, and change what they display if a user is not allowed to see a field.
This is big for any company that has different brands or wants to be able to market differently for products or divisions. Two big points are: