This posts summarizes most Winter 21 new features related to Lightning Flow. To test these new features now, you can sign up for a pre-release org here.

1- Trigger a Flow to Run Before a Record is Deleted

In Flow Builder, you can now configure a new record–triggered flow to run before a record is deleted. You no longer need to write Apex code to set this up. This autolaunched flow runs in the background and updates related records when a record is deleted.

2- Debug Autolaunched Flows Directly on the Canvas (Beta)

Now you can debug an autolaunched flow without opening a new browser tab. Just click Debug on Canvas (Beta) in Flow Builder and view the path the flow took during the debug run.

3- Build Multi-Column Screens in Flow Builder (Pilot)

Multi-column layouts have hit Flow Builder! You can use the new Section component to arrange your flow screen components into multiple columns without touching a single line of code. Divide each flow screen into multiple sections, and easily modify the number of columns in each section to create effective, visually appealing layouts. Contact your Account Executive if you’re interested in participating in the pilot.

4- Debug Flow Errors in Sandbox Org as Another User:

Debugging a flow in a sandbox org is now easier than ever with the ability to debug a flow as another user. When you debug a flow as another user, you can catch flow exceptions such as unexpected permission, sharing, and profile configurations before they occur in production orgs.

Note: to enable this feature, go to Setup – Process Automation Settings, otherwise you will receive the below. 

5- Improve the Performance and Precision of Record-Triggered Flows with Entry Criteria

Salesforce added entry criteria to record-triggered flows, giving you more control over your automation. Instead of configuring the flow to run every time a record is created or edited, you can now configure it to run only when condition requirements are met. This optimization can also significantly reduce your record-triggered flows’ impact on your org’s performance, depending on the flow.

6- Create Decision Outcomes that Only Execute When Certain Changes are Made

Now a flow 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 feature allows you to filter out record updates that are unrelated to your flow’s use case, and to avoid reprocessing records that previously triggered the flow.

7- Use Auto-Layout to automatically place and connect elements in flow

The new auto-layout feature makes building flows and aligning elements easier. When auto-layout is enabled on a flow, elements in the canvas are spaced and connected automatically. No more elements positioned slightly out of alignment!

8- Access Related Record Data In Autolaunched Flows With Triggers Using $Record.

We do not need to have a Get Records flow element to retrieve associated record information. You can access the related data via the $Record element.

9- Quickly See the Triggers of Your Flows on the Flows Page in Setup

Now see which trigger your autolaunched flow has with just a glance at the Flows list view in Setup. In the new Trigger column, see if a flow’s trigger is a record, a schedule, or a platform event. For a record-triggered flow, see if it makes before- or after-save updates. You can also discover which trigger an autolaunched flow has by viewing the flow’s detail page.

10- Lightning Flow Run-Time Improvements in API Version 50.0

ISBLANK function returns true for empty string or null values

In flow and process formulas, the ISBLANK function returns true for empty string or null values. In flows and processes that run in API versions earlier than 50.0, the ISBLANK function returns true only when the value is null.

Enforce each flow screen’s Next or Finish control navigation setting

When Next or Finish is deselected in a flow screen’s control navigation settings, the screen no longer displays the Next navigation option to users. For flows that run in API versions earlier than 50.0, the Next or Finish setting isn’t always enforced. Specifically, screens always display the Next option when an element is in the flow after the screen.

Let merge fields support null record variables

Merge fields that reference record variables no longer cause errors when the record variables are null at run time. For flows that run in API versions earlier than 50.0, a merge field such as {!Account.Name} causes an error when the account record variable is null at run time.

Enforce the running user’s data access when a flow uses a merge field

This versioned update enables the Enforce Data Access in Flow Merge Fields release update for flows that run in API version 50.0. After the release update’s auto-activation, the update will be enforced for all flows regardless of their run-time API version. 

Treat invalid references to global variables as errors instead of string values

At run time, an invalid reference to a global variable now results in an error. In flows that run in API versions earlier than 50.0, invalid references to global variables are treated as string values. For example, suppose that a flow screen contains a Display Text component with this typo: Hello {!$User.FirstNaame}! If the flow runs in API version 50.0 or later, an error occurs when the Screen element is executed. If the flow runs in an API version earlier than 50.0, your users see “Hello {!$User.FirstNaame}!” on the screen.

 

To get the full Winter 21 release notes for Lightning Flow, please visit this link. 

In the Winter ’20 release, Salesforce introduced scheduling autolaunched flows, which made it possible to schedule actioons decalatively within Salesforce. Prior to that, the only way to schedule anything in Salesforce was through Asynchgronous Apex, specificaly by implemeting the Schedulable interface. 

To schedule autolaunched flows, you need to specify the date and time the flow will run as well as its run frequency: once, daily, or weekly. Optionally, you can specify a specific Object with a filter that returns specific records of that Object, where the flow would run against. 

Here’s the session explaining scheduling Salesforce autolaunched flows, with 2 demos ar the end:

1. Scheduling sending an email using the “Send Email” action
2. Scheduling mass-updating Account records on a daily basis

These considerations apply to scheduled flows.

• A scheduled flow starts at the specified time and frequency. You can’t launch a scheduled flow by any other means.
• The Start Time field value is based on the org’s default time zone.
• The View All Data permission is required to activate an autolaunched flow that has a trigger.
• The maximum number of scheduled flow interviews per 24 hours is 250,000 or the number of user licenses in your org multiplied by 200, whichever is greater.

  If you specify an object so the flow runs for a batch of records, set the time, frequency, and record conditions to avoid reaching this limit. You can use debug logs to check how many records a scheduled flow runs on. Track the number of records with the FLOW_START_SCHEDULED_RECORDS event. If your org reaches the limit, Salesforce sends a flow error email.

• If you delete a scheduled flow from the Scheduled Jobs page in Setup, all future recurrences of that flow are canceled. To enable future runs, deactivate and reactivate the flow.
• A scheduled flow doesn’t run if it’s scheduled to run once with a date and time that has already passed.
• The Automated Process user runs scheduled flows.
• If you need a scheduled flow to invoke Apex code, don’t activate the Require User Access to Apex Classes Invoked by Flow critical update. When that critical update is activated, the scheduled flow fails when it invokes Apex.
• If you configure an Update Records element to use the ID and all field values from the $Record global variable, enable Filter inaccessible fields from flow requests in your org’s process automation settings. Otherwise, the flow fails because the Update Records element tries to set the values for system fields and other read-only fields.
• When you define multiple filters, the filter logic usually defaults to AND. However, if multiple filters have the same field selected and use the equals operator, the filters are combined with OR.

  For example, your filters check whether a case’s Type equals Problem (1), Type equals Feature Request (2), and Escalated equals true (3). At run time, the filters are combined to (1 OR 2) AND 3.

Use Case:

Marie Sloan, a Salesforce Admin, is asked to build a Round Robin assignment tool to assign Survey records to Agent records following a Round Robin way, which means that  the total number of Survey records to assign should be divided by the number of Agents, and each Agent should be assigned an equal number of Survey records. For example, if we have 3 Agents and 36 Surveys, each Agent will be asigned exactly 12 Surveys. 

 

Object Model:

To tackle this requirement, let’s first explain the data model required to illustrate this example:

1. Custom object called Round_Robin_Assigner__c  This is the object that will be used to initiate the Round Robin assignment. The fiels are:
   1. Name: auto number field with display format: RR-{000}
   2. Number_of_Agents__c: Rollup-Summary field that counts the number of Agent__c records associated with this Round_Robin_Assigner__c record
   3. Number_of_Surveys__c: Rollup-Summary field that counts the number of Survey__c records associated with this Round_Robin_Assigner__c record
2. Custom object called Agent__c with the following fields:
   1. Name: auto number field with display format: A-{000}
   2. User__c: lookup field to the User object
   3. Round_Robin_Assigner__c: Master-Details field to the Round_Robin_Assigner__c object.
3. Custom object called Survey__c with the following fields:
   1. Name: auto number field with display format: S-{000}
   2. Tag__c: auto number field without any display format. This field simply represents the tag, or Id of eacj Survet record, it is automatically added to each survey, and no 2 surveys will have the same Tag number. This field will be used to calculate the Assignment_ID__c field below.
   3. Assignment_ID__c: formula field used to give the assignment ID to each Survey record, based on t he total number of Agents and the Tag on each Survey. More details to follow below.
   4. Round_Robin_Assigner__c: lookup field to the Round_Robin_Assigner__c object. This is the field that will be filled to assign an Agent to the Survey.

Here is the ERD:

To futher explain what’s going on,

1. the main object (1) Round_Robin_Assigner__c is the parent of both:
2. the object to assign, in this case (2) Survey__c
3. the object to assign to, in this case (3) Agent__c.

In other words, if we want to assign Agent__c records to Survey__c records, first, we create a Round_Robin_Assigner__c record, second, we add to it all the Survey__c records that we want to assign, and third, we  add all the Agent__c records that should be assigned to Survey__c records. The Round_Robin_Assigner__c record will hav a button that will launch a flow to assign the Surveys to the Agents in a Round Robin fashion! Simple!

Now, let’s explain the fields on each object…

First, the Round_Robin_Assigner__c object has 2 Rollup-Summary fields that count the number of Agent__c and the number of Survey__c associated with it. The field names are Number_of_Agents__c and Number_of_Surveys__c. 

 

On the Survey__c object:

• The Tag__c field is simply an auto-number field that gives a unique number to the record. The first Survey__c record has Tag__c = 1, and so on.
• The Assignment_ID__c field is the field used to assign the Survey__c to the Agent__c. It is a Fomrula field with this Formula:

1 + MOD(Value(Tag__c), Round_Robin_Assigner__r.Number_of_Agents__c)

This MOD function will take the MOD of (1) the Tag number value of the Survey__c record – we uses the Value() function to take the number value of this auto-number field, and (2) the total number of Agent__c records associated with this Round_Robin_Assigner__c record. So, if we have 5 Agent__c records, and 100 Survey__c records,

• For example, the record wih tag 50 would have 1 + MOD(50,5) = 1 + 50 MOD 5 = 1 + 0 = 1,
• the next record would have 1 + MOD(51,5) = 1 + 51 MOD 5 = 1 + 1 = 2
• the next 1 + MOD(52,5) = 1 + 52 MOD 5 = 1 + 2 = 3
• the next 1 + MOD(53,5) = 1 + 53 MOD 5 = 1 + 3 = 4
• the next 1 + MOD(54,5) = 1 + 54 MOD 5 = 1 + 4 = 5
• the next 1 + MOD(55,5) = 1 + 55 MOD 5 = 1 + 0 = 1
• Etc…

This way, the Assignment_ID__c field will dictate which Survey record goes to which Agent, based on the above math.

Next, we will add a Flow to assign the Agent__c field to the Survey__c records. 

Create the Flow:

Create a new Screen Flow, and in it first, create the variable that will hold the Id of the Round_Robin_Assigner__c record that will have the button to launch the flow. Remember, the variable name should exactly be ‘recordId‘ with the letter ‘I’ in a capital case.

To start, let’s create 3 “Get Records” elements: 

• Get Assigner: to get the details of the 1 Round_Robin_Assigner__c record that has the Id recordId. Store the variable in the Record Variable sov_Assigner. 
• Get Agents: to get all Agent__c records that are children of the above Round_Robin_Assigner__c record. Store the variable in the Record Variable socv_Agents. 
• Get Sutveys: to get all Survey__c records that are children of the above Round_Robin_Assigner__c record. Store the variable in the Record Variable socv_Surveys. 
• I will only show the screenshots of the first and second “Get Records” elements above. 

Now, create 2 Number variables and an Assignment element to assign them values:

• v_Agent_Total_count = {!sov_Assigner.Number_of_Agents__c}. This is the rollup summary field that countsthe number of Agents related to this Round_Robin_Assigner__c record.  
• v_Agent_Counter = 1. This will set the counter to 1. 

Create the first loop:

• Purpose: loop through all the Agent__c records that are related to the Assigner__c record. For each agent, get all the Survey__c records with an Assignment Id equivalent to the Agent. 
• Name: Loop through Agents 
• Collection Variable: socv_Agents 
• Iteration Direction: First item to last item
• Loop Variable: socv_agents_single

 

Inside this loop, get the Survey__c records with an Assignment Id equivalent to the Agent. For that, we will use use variable v_Agent_Counter. All these syrveys will be stored in a Record Variable called socv_Specific Surveys. 

Create a second loop inside the first loop:

• Purpose: loop through all the Survey__c records with an Assignment Id equivalent to the Agent, and add these to a “Record Variable” to assign them at the end to the Agent. 
• Name: Loop through specific Surveys 
• Collection Variable: socv_Specific_Surveys 
• Iteration Direction: First item to last item
• Loop Variable: socv_Specific_Surveys_single

Inside this second loop, assign the Agent Id to the Agent__c field of the Survey. Then add this Survey to a new Record Variable called socv_Surveys_to_Update. To do so, create the Record Variable, then create an Assignment element to add the single Survey__c record to the socv_Surveys_to_Update. 

After exiting the second loop, increase the Agent Counter variable by 1

Finally, update all the Survey__c records at once, using a Record Update element on the socv_Surveys_to_Update record variable. 

You can then add a Screen element with any information you want:

And this is the final Flow:

Now, activate the Flow, then add a New Action  that calls this Flow from within the Round_Robin_Assigner__c object. 

Let’s run thre Assigner! Here is a screen before clicking on the button, and then the result aft.er. Notice that each Survey ois now assigned to a specific Agent!

You can modify the objects based on your requirements, but the idea is the same! 

Cheers

Walid