- Locate Lightning App Builder header and toolbar buttons.
- Deploy organization-wide defaults and criteria-based sharing rules together.
- Develop flow screen components that work for multiple objects.
- Break up your record details with Dynamic Forms.
- Debug flow errors in a sandbox org as another user.
- Flow enchantments : ‘Before-Save’ and ‘Is Changed’ capabilities
1. Lightning App Builder changes
- Back button moved to far left
- Look of Refresh button is changed
- New button called Analyse in record pages to do analysis for new performance
- Colour changes of Save and activation button to Blue and white
2. Deploy OWD and Criteria based sharing rules together
You can simultaneously update “sharing model” field for an object and create new criteria based or guest user sharing rules via metadata API.
Previously: One need to do these changes in separate packages but now can be done simultaneously. Though you can still deploy owner based sharing rules separately from OWD changes.
3. Develop Flow screen elements for multiple objects
You can Create reusable flow screen components that use generic sObject and sObject[ ] data types
For multiple objects, you can build one component.
Example: If you build data table component , it would work on accounts and contacts to custom objects from any collection of records.
4. Record details break up with Dynamic forms
- It is only for lightning record pages
- You can Configure record detail fields and sections inside the lightning app builder
- With dynamic forms, easily one can migrate fields and sections from page layout as individual components
- Configure it like rest of components
- Give users only fields and sections that they need
- Now Dynamic forms enabled for everyone
- Feature is available in lightning APP Builder
- To activate that, Go to One of the Record page in Lightning App Builder and click on Upgrade Now from Record detail Properties Panel
Note: Dynamic Forms is supported on record pages for custom objects only.
5. Debug Flow errors in Sandbox as another User
- Path: Setup- Quick find box- Process automation settings – select check box- Let admins debug flows as other Users
- Open flow builder and go to Flow- debug and option would be available as to run flow as another user.
- This is only available for screen flows and auto launched floes in Non Production orgs.
- It supports flow elements and actions only
- Screen components include Aura components, custom lightning web components and some standard flow screen components such as Lookup components.
6. Flow enchantments: ‘Before-Save’ and ‘Is Changed’ capabilities
Creating or updating a record can now trigger an auto-launched flow to make additional updates to that record before it’s saved to the database. Before-save updates in flows are much faster than other available record-triggered updates. For example, a before-save update in a flow is 10 times faster than an update in a record-change process that’s built in Process Builder.
It’s similar to ‘before Trigger’. When you save that, before save updates are executed immediately prior to Apex before Trigger
Sometimes you need to use a record-change process or an Apex after trigger to:
- Access field values that are set only after the record is saved, such as the Last Modified Date field or the ID of the new record.
- Create or update related records.
- Perform actions other than updating the record that launches the flow.
Four Elements are offered for before save updates Flow;
- Get Records
You can use these elements to decide whether to update the triggering record’s fields and to what values
The $Record global variable contains the values from the record that triggers the flow to run. As a result, there’s no need to add a Get Records element to obtain the record data or create flow variables to store the record data.
When the flow changes the values in the $Record global variable, Salesforce automatically applies those new values to the record. So there’s no need to add an Update Records element to save the new values to the database.
‘Is Changed’ feature
You can set the path for a flow to filter out records which are unrelated to your flow’s use case and unnecessary reprocessing of records that previously triggered the flow.
A flow that’s triggered by a record update can take different paths if the record that triggered the flow was edited to meet certain criteria.
When you configure a Decision outcome, you can now set that outcome to execute only when the triggering record is updated to meet the condition requirements.
This option gives your flows a powerful filtering feature similar to the ISCHANGED function found in Workflow Rules and Process Builder and the old Map/new Map variables found in Apex.
Build more of your automation directly in Flow Builder without requiring Process Builder or Apex to check the prior version of the data.
This option checks if the triggering record didn’t previously meet the criteria and if the $Record variable, not the triggering record, now meets the criteria.
If your flow changes any of the $Record variable’s fields before it runs the configured Decision element, the Decision checks if the $Record’s new field values now meet the criteria