The Summer ’21 release is here, with the host of new features we’ve come to expect. Here are the top 10 items that jumped out at me, with a disclaimer that my bias continues to be towards Platform/Customization, Service Cloud and Revenue Cloud. Note that Flow features are now referred to as ‘Einstein Automate’, and that team continues to churn out features at a furious pace.
While the Flow improvements seem the most impactful to me overall, I’ve tried to vary this post to include other features as many others have already covered the Flow changes in better detail than I can — I’ve linked to those experts below and recommend that you check them out for better detail!
UnofficialSF / Alex Edelstein: Summer ’21 Flow Preview. This ultimate guide to all things Flow.
ForcePanda / Narender Singh: Summer ’21 Flow Sneak Peek.
SalesforceBen / Tim Combridge: Summer ’21 Treasure Hunt.
AccidentalCoder / Vibhor Goel: Another Flow preview guide.
Salesforces News Technology Stuff / Tushar Sharma. Another good Flow preview.
Daryl Moon is all over the Release features on LinkedIn. Also, Parthiban Vijayan and Aniket Kohale are sharing individual pulls from the Release Notes on LinkedIn pretty frequently so check them out as well.
10. Flow Debugging – Continue Debug After Pause Element
We can now debug Flows through Pause elements. This one is personal as I had a specific use case that was very difficult to debug using Pause, and so I’m perhaps overhyping this one. See that post here about using Pause element to ‘babysit’ Managed Package behaviors. The short of it is that prior to this change, when a Pause element was reached in the Flow that was the end of your debug session. This required activation of the Flow and testing against the process directly to see if your build matched requirements. Now we can debug through the Pause by declaring the path to take out of the element. This will really help in dealing with Pause elements in Flows.
9. Salesforce Field Service – Shifts Improvements
I recently spent some time putting together a proof of concept using Shifts, and was really impressed with the flexibility it provides for complex scheduling requirements. Shifts effectively override standard Operating Hours so that we can apply a custom schedule for resource availability. In Summer ’21 release, the creation process for Shifts is further simplified by not requiring territory up front, allowing a year of pre-config, etc. and it will be interesting to see further growth in this area.
8. Sharing – Check Record Access Reasons
‘Sharing Hierarchy’ button is available in Lightning and provides a detailed report of which users have record access and why. This is key in troubleshooting visibility concerns, and now we don’t have to go back into Classic to check for this information. This is available on Accounts, Opportunities, Cases, Contacts, Leads and Custom Objects at this point.
7. Flow Debugging – Debug Record Triggered Flows
Record-triggered Flows have been a tremendous tool since their introduction, but the ability to debug against a particular record was missing. This led to a lot of ‘Activate’ and then run records to try to figure out whether the behavior matched expectations. With Summer ’21 the ability to debug record triggered Flows has been added. Interestingly I don’t see this in the early version of the release notes, so am relying on the aforementioned experts. To Debug, select the record that is being created/updated and the debugger simulates that record entering the Flow. Rollback mode is also available.
6. Tableau CRM Salesforce Output Connector
This feature is now GA, and allows for data preparation in Tableau CRM and then insert/update back into Salesforce records. I’m excited to check this out as a tool for consolidating data from multiple sources and writing the output to Salesforce. Chris Ames has a great post on this on salesforceblogger.com that provides detail.
5. Flow Builder – ISCHANGED in Start/Decision and ISCHANGED, ISNEW and PRIORVALUE In Flow Formulas
Twofer here around Flow condition logic and some of the last holdouts that led to use of Process Builder/Workflow Rules over Flow in terms of declarative development…
Record-triggered Flows allow formulas to reference ISCHANGED, ISNEW and PRIORVALUE in formulas. This will let us control behavior, or reference old values, in the Flow. For example, when a record enters record-triggered Flow, we can see if specific fields were changed, or compare old value to new value and drive logic accordingly.
Importantly, ISCHANGED is also available for Start and Decision conditions in record-triggered Flows. In the Start elements we can thus enter the Flow only if certain fields are changed OR certain fields are not changed. In the decision element we can branch on whether or not a field has been changed as well.
This greatly increases the power of record-triggered Flows, and strikes a finishing blow to the argument for using Process Builder over Flow.
4. Permission Set and Permission Set Group Expirations
Ranking solely on the basis of timeliness vs. current needs, I’d have this as #1. Given the shift to Permission Sets and Permission Set Groups, having time-based control over assignments is a big win. With this feature, we can temporarily assign Permission Sets with a given expiration date, which prevents the need for jobs to clear them, manual review procedures, or otherwise forgetting and leaving access in place beyond when it is needed.
3. Flow Builder – Use Fields from Record In Flow
For the first time, we can now select fields for screens from the record itself and entered values are assigned automatically. This makes obsolete the need to add generic fields, and then map the inputs for those fields to the SObject via an assignment element. Additionally the default value will be set automatically based on the value in the record itself, thus simplifying screen element setup. At this point only the standard field types are supported (not the ‘Lightning Component’ types like Lookup and Picklists for example) — Checkbox, Text, Date, Date/Time, Number, Text Area, Text Area (Long). As additional build-out is done in this direction, this could be the next huge breakthrough from Flow.
2. Reports – Update Records Inline
Now in Beta is the ability to edit records that are displayed in Reports. This will allow for data maintenance from within reports themselves, which offers a great way to review and correct errant master data. Currently you have to open records individually to make the edits, or try to craft a matching List View to use inline editing. This feature will be a big time saver for admins and data maintenance roles.
Note that there are a number of limits in place at this time, and the following field types are not yet supported: Picklists, Compound fields, date/time fields, and master-detail lookups being the main ones. Note that ability to edit will be governed by page layout restrictions just like in List view inline editing.
1. Flow Builder – Choices Overhaul (UnofficialSF Refers to as Choiceapalooza)
Multiple changes around choices and picklists are available in Flow. See full post on ‘Choiceapalooza’ features here on UnofficialSF. There are a few improvements brought here that are of particular interest.
Multiple changes for default values on picklist choice sets or record choice sets. Of particular interest, we can now default multiple values in multi-select checkbox components. This works for matching of values against choices as well as for record choice sets (using record Id as value). The release notes provide the table below for understanding the default behavior.
| If your default value is… | Then at run time we preselect choice options based on… |
|---|---|
| A choice resource that’s included in the list of choice options for the component | A match for the selected choice’s API name. |
| A choice resource that’s not included in the list of choice options for the component | The resolved value of the choice resource. If a given choice’s value matches the resolved default value, then that choice is selected. |
| Another resource in the flow such as a reference from a Get Records element | The resolved value of the flow resource. If a given choice’s value matches the resolved default value, then that choice is selected. |
| A manually entered value | The manually entered value. If a given choice’s value matches the manually entered value, then that choice is selected. |
Next, picklists can now be set as required, and the –None– (null) option is included in picklist choice set to require that a selection actually be made. This was previously a source of frustration and an area that required a workaround to set a ‘bad’ value to force that a user interact with the picklist by checking in flow validation that the ‘bad’ value was no longer selected.
Lastly, and this is one that I really wish was in place when building out a full SFS Mobile App using flows, is the ability to change Components using choices without having to re-enter all of the choices again. So we can switch between radio buttons and checkbox groups without having to re-do everything. This is a significant time-saver when building and refining Flows at scale.
Thanks for reading, and hopefully this contributes to the excitement for Summer ’21 !
