The list of Winter ’19 features below apply to both Salesforce Lightning Experience and Classic.
There are additional Winter ’19 features available to Salesforce Classic Only, Lightning Experience only, Community Enhancements, Other Enhancements in the Winter ’19 Release Highlights post.
Note: These features are not listed in any specific order.
1. Starting with Winter ’19, field history will not be maintained beyond 18 months, except if you have purchased the Field Audit Trail add-on. Previously, Salesforce had not enforced the 18 month history retention policy.
2. Survey enhancements
3. Reject leads generated from a Web-to-Lead that don’t use reCAPTCHA verification.
4. Attachments to newly received Email-to-Case messages are automatically converted into Salesforce Files so customer service reps can preview the attachments without navigating to the case record’s files related list. To use this feature for orgs created before Spring ‘18, the Admin needs to enable Save Email-to-Case Attachments as Salesforce Files.
5. Developers can now edit custom metadata records in memory within Apex. Previously, custom metadata records queried with SOQL in Apex were immutable. Note: DML operations aren’t allowed on custom metadata in Apex. This needs to be handled via the Apex Metadata API.
6. Admins can reference custom metadata types in formulas to avoid hardcoding.
7. Updated default limits for flows and processes (https://releasenotes.docs.salesforce.com/en-us/winter19/release-notes/rn_forcecom_flow_design_limits.htm)
8. (Pilot) Where is This Used? – Find custom field references in the org
9. New usage based entitlements for processes and flows:
10. Enhancements to flow screen components (Note: Screen components are supported only in Lightning flow runtime):
a. Display dependent picklists up to three levels. Select the lightning component flowruntime:dependentPicklists. Configure the picklist fields in the the Inputs tab.
b. Use the name form for up to 6 different fields. Select the lightning component flowruntime:name. Use the Inputs tab to configure the heading that appears above the name fields and which name fields to display.
c. Use a toggle instead of yes/no, true/false or on/off. Select the lightning component flowruntime:toggle. Use the Inputs tab to configure the toggle label.
d. Use a number selection slider. Select the lightning component flowruntime:slider. Use the Inputs tab to configure the slider’s label and range.
e. Capture an email address provided. Select the lightning component flowruntime:email. Use the Inputs tab to configure the email field label, default value and placeholder text.
f. Capture a phone number. Select the lightning component flowruntime:phone. Use the Inputs tab to configure the phone field label, placeholder text and the pattern for valid values.
g. Capture an URL. Select the lightning component flowruntime:url. Use the Inputs tab to configure the URL field label, default value and the pattern for valid values.
h. Retain previously entered values from flow screens. Flow has no memory. It does not retain the information between screens. However, flows can remember a value for an attribute you configure in both the Inputs and Outputs tabs of the screen component.
11. Salesforce recommends one record change process per object, just like triggers. This allows you to control the order of execution and avoid exceeding limits like SOQL queries. Now, when you create a new record change process, Salesforce will list the active processes for that object.
12. Add custom validation to your flow custom screen components. Add a validate attribute of type Aura.Action to your component’s declarations. For an example, see the release notes.
13. Install flow solutions from the AppExchange. Click Solutions by Type, then click Flow Solutions.
14. Use autolaunched flows with Einstein Bots (Note: Einstein Bots is available to orgs with both Service Cloud and Live Agent user licenses.)
15. Deploy a new active version of a process or flow via change sets or Metadata API instead of deploying it as inactive and manually activating it post deployment. On the Process Automation Settings screen, select “Deploy processes and flows as active.” NOTE: With this change, in order to successfully deploy a process or flow, your org’s Apex tests must launch at least 75% of the total number of active processes and active autolaunched flows in your org.
16. Salesforce has introduced two Tooling API objects to calculate the test coverage. FlowTestCoverage represents test coverage for a flow by an Apex test method. FlowElementTestCoverage records are created when an Apex test method executes a flow element.
If you are using the API version 44.0, when you retrieve or deploy the most recent version of a flow, the flow version is no longer attached.
17. Salesforce now supports session index parameters with SAML single logout (SLO) which can help identify which user session to terminate.
18. For your community, you can specify different login policies for internal users logging into the community versus logging into the Salesforce app.
19. Salesforce Shield Enhancements:
a. Update tenant secret status and schemes through an API
b. Encrypt custom object name fields
c. Apply shield encryption to health cloud fields
d. [BETA] Apply encryption to rich text fields
e. Use Shield Platform Encryption to encrypt change events (change data capture)
f. Apply encryption to components in change sets
20. Opt out of instanceless My Domain URLs. Summer ‘18 introduced instanceless My Domain URLs. However, some older plug-ins from the AppExchange may not yet work with instanceless My Domain URLs and therefore, you want to deactivate the critical update that will automatically be activated on March 16, 2019.
21. Access the Metadata Coverage report which displays current metadata coverage across the Metadata API, Source Tracking, Unlocked Packaging, Managed Packaging, Classic Packaging, Change Sets and Apex Metadata API channels. Go to https://developer.salesforce.com/docs/metadata-coverage.
22. With scratch org settings, you can spin up and configure your scratch orgs with any Metadata API setting.
23. Mark an Apex method as storable (cacheable) rather than using setStorable() on every JavaScript action to mark the apex method as cacheable. Use @AuraEnabled(cacheable=true) in your Apex method instead of @AuraEnabled
24. New and changed lightning components
25. Apex Replay Debugger (GA to be released around October 13, 2018) simulates a live debugging session using a debug log, which is a recording of all interactions in a transaction, to debug apex code.
26. Use Visual Studio Code to view test results and jump directly to a failed assertion in the test results.
27. Improved security enhancements for Visualforce:
a. Use the IMAGEPROXYURL function on the src attribute of a <img> tag or the value attribute of an <apex:image> object to securely retrieve an external image
b. Use $IFrameResource.<resource_name> as a merge field, where resource_name is the name you specified when you uploaded the static resource, to reference a static HTML file that resides on a separate domain.
c. Protected URL parameters used in Visualforce pages (i.e. retURL, startURL, cancelURL, and saveURL) are no longer case-sensitive.
28. Use the Metadata REST API with all deployments, using either the new deployRequest REST resource or Salesforce CLI.
30. Unlocked Package enhancements:
a. Patch version numbers now available
b. To extract an unlocked package’s dependency information, you can either run a simple SOQL query or create a script to automate the installation of unlocked packages with dependencies.
c. You can now deprecate metadata in an unlocked package, move that metadata to a new package, and install the new package in your production org. Previously, you had to manually delete the deprecated metadata before you can install the new package that contains the metadata.
31. Receive streaming events in lightning components
32. You can now fire platform events in your batch apex classes when encountering an error or exception.
33. Use the inherited sharing keyword in your apex. Unlike an omitted sharing declaration, an Apex class with inherited sharing runs as with sharing when used as a Visualforce page controller, Apex REST service, or an entry point to an Apex transaction. A class declared as inherited sharing runs only as without sharing when it is explicitly called from an already established without sharing context.
Jenwlee's Salesforce Blog 