How cool are the brand new start element formulas?
One of the best use cases for it is the Record Type criteria. You can now check for the RecordType.DeveloperName or the RecordType.Name in your start element. This was not possible before. You either had to hardcode the RecordType.Id or defer the criteria to a decision element, making the flow less efficient.
What else can we do with start element formulas?
When you want to trigger your flow in case the triggering object record is created or updated, and you want to build sophisticated criteria, then the formula entry conditions are ideal for this purpose.
A popular use case is the auto-naming of records when a new record is created. For example, you can append the Industry picklist value to the Account name using a before-save flow.
Here is the formula resource that does that:
The difficulty is when you want to trigger such flow on create and update. If you don’t build your flow carefully, you will append the same thing to the name multiple times based on multiple updates. You will need to check whether the auto-name logic ran before if you want to avoid this outcome.
Here is the start element formula that ensures that:
I recommend you go and play with this functionality yourself if you haven’t already. You will like it. It is super powerful.
This is the only area where we have a function, a logical operator picker, and a syntax check button within flow.
If you have comments on this topic, please join the discussion on Twitter or LinkedIn.
How powerful are the collection sort and collection filter elements? How should you use them?
I experimented with collection filter and collection sort elements to see how far I can go using only one get element. In other words, I wanted my flow only to use up one SOQL against the governor limits.
I started with a get element that returns all the cases that have both account and contact assignments. I was able to extract the following information with only one get element:
Most Recently Modified Case
Oldest Modified Case
Oldest Modified Case Account Name
Number of Cases by this Account
Most Recently Closed Date for this Account
Contact Id on this Case
Number of Cases for this Contact
Oldest Closed Date for this Contact on this Case
Please see the image for the results.
How many elements did I use? Did I have to loop?
Here are the answers:
Your get element gives you sorting functionality. Use it.
You have to loop to get the min and max values, such as the oldest and most recent, sorted by Date and Time. But you need to loop only for one iteration. So you can exit after you assign the first record to a variable.
Your loop can use the existing sort or the reverse sort. Use this functionality.
Initially, I used a counter variable to exit the loop, but this was unnecessary. You need to exit the loop regardless after the first iteration. Insert a decision and connect both branches to the next element outside the loop.
You can get a count of records by using an assignment element with the operator “equals count”.
I experimented with the formula criteria inside the collection filter element without much luck. I think this functionality does not allow for filters with variable values on the right side of the equation. “ContactId on the current record = ContactIdVariable” formula did not work.
What do you think? Can these elements save you lengthy loops and executed elements?
How many elements, excluding the start or the end element, did I use to extract this information.
I have a quick but important update for you this week.
An issue I see quite frequently happens when folks try and remember to use the assignment element instead of the update element in record-triggered flows. You can indeed use an assignment element instead of an update element in a before-flow to change the field values on the record that triggered the flow. However, this is not true when running your record-triggered flow in after-save mode.
To avoid confusion and facilitate an easy transition between before-save and after-save, always use the update element in a record-triggered flow to update the field values on the record that triggered the flow.
I am sure you know by now; before-save is labeled as Fast Field Updates, and after-save is labeled as Actions and Related Records in the record-triggered flow start element configurator.
If you have any questions, please do not hesitate to ask them on the Salesforce Break Slack. The invitation link is on https://SalesforceBreak.com.
Content and event updates:
Orchestrator: Brian Kwong has a super nice recording of an orchestrator built on YouTube. It is no secret that I like live sessions and tutorial-style recordings. Click here to watch the Orchestrator video.
Let’s talk about the brand new collection filter element this week.
I wrote a newsletter issue about the get element before. Get elements are essential. They can query the Salesforce database and get multiple records for you. The corresponding functionality in coding is called SOQL. However, SOQL is much more powerful than the get element.
Get element and flow limitations can force the low-coder to build loops inside loops to process related records. When you are forced to build a solution like this, you should seriously consider whether flow is your best option.
When you loop within loops and start getting records, you run up against two limitations of flows:
You can only do up to 100 gets or SOQL’s in one synchronous transaction.
You can only process up to 2,000 elements in one flow interview.
This is where the new collection filter element comes to the rescue. For example, let’s say you need to get the cases for a specific contact under one account and show the case field values to the user. In the beginning, you can query all cases under the account. Then, you can show the user a few selection screens in your screen flow; finally, show the case field values and have the user edit them. Then, the user can go back to the contact selection screen and do it again for another contact. You can do all that using the new collection filter element without using another get element again after the first get execution.
Remember that your choice elements in your screen flows can accept collections as choices starting with Spring 22, as well.
But something even more impressive is offered with the new collection filter element. You can now use formulas to decide which records you select and add to your filtered collection.
You want to filter Account records with Annual-Revenue/Employee ratio within a specific range. Prior to this release, you had to create a formula field on the Object to show the Annual-Revenue/Employee calculation result. You don’t need to do that anymore. Instead, you can use a formula in your collection filter element to select records that have Annual-Revenue/Employee = $100,000, for example. This is huge.
If you don’t understand some of the concepts and the terms used in this newsletter issue, you may want to read get element issue here.
Recently published content:
My dear friend Daryl Moon and I had a live video chat o Flow Tips today on both LinkedIn and YouTube. Watch the YouTube recording here.
Let’s dive in to get elements this week. Get elements, a.k.a. SOQL queries, get one or more values from the Salesforce database. These values can be used later in our flow.
Before we go deeper into the get element, we need to talk about variables. Variables are containers in Salesforce that keep values for us temporarily until we use them. This is kind of like writing something on a napkin rather than in the address book. To save values permanently, we write them to the database; in other words, we write them in a record and save/commit to call and use them later. On the other hand, variables are available only in the flow we are in, and they vanish after we complete our flow interview.
In Salesforce flows, we create variables on the left panel in the resource manager, and some others are automatically created for us.
When we get a complete record, for example, Salesforce creates a record variable automatically and saves all the values of the get element in this variable.
Let’s assume we find only one opportunity record match in our get step labeled as “Get Account”. Salesforce auto-creates a get element record variable with all the field values that are available under that record. As flow makers, we can refer to one or more field values in that variable when we are building our flows – in this case {!Get_Account.Id} – for the recordId. What are the parameters we need to set to execute a successful get step?
Typical scenario: We would like to find all Accounts with the name ACME.
Setup: Tell your get step you want to get a record of Account object type.
Set the filter condition as Account Name equals ACME. What are the possible outcomes here? We may find:
No records
One record
More than one records
Let’s look at these possibilities:
No records: Your get step won’t fail. However, you will get a record variable automatically created with the value null assigned to it.
One record: You will have one record in your record variable complete with its recordId, name, and all other field values. You can use these later in your flow.
More than one record: You have options here. First, you can tell the get element whether you need to sort these records according to one field value. Then you can decide whether to get and assign the first record to a record variable or assign all the records to a collection variable (this means N number of containers of the same type). All these are auto-created for you.
One important tip here is to catch the “No records” outcome. If you don’t do that and use the record variable later in your flow, you will receive an error message, and your flow will fail.
So insert a decision step right after your get element and check whether {!Get_Account} is null true. If that is the case, stop all operations and exit the flow gracefully. In screen flows, you can insert a screen element to show the user a message explaining what happened.
Use the filter criteria wisely because if your get element returns more than 50K records, you will hit the governor limit, and your flow will fail.
This wraps up everything I wanted to write about the get element this week:
Recently published content: How do you extend upsell/crosssell offers using a screen flow on a Lightning page. Click here to this Salesforce San Francisco User Group Video on the Salesforce Break Youtube Channel to learn.
Do you need to see advanced use case flow applications for inspiration? Click here to watch the short video on a Loan Application Use Case.
