Datatable Component – Salesforce Screen Flow

The Salesforce Flow Datatable component allows users to easily display and select data in a table format, making it ideal for various flow builds. The Salesforce Flow Datatable component enables users to sort, filter, and search through data.

There are mainly two screen flow areas I use the Datatable component for:

1) Related record operations: I need the user to select single or multiple records related to a record the flow is working on—for example, contacts on the account or cases on the contact.

2) Menu choice options: When I branch my screen flow logic, I need to give the user a choice that involves showing data in multiple columns. For example, add a product to the Opportunity.

In the latest release, the Datatable component received a few nice updates. Now we can add a search box on top of the Datatable. And a few limits have been updated: The component can show up to 1,500 records and supports a selection of up to 200 rows.

There are excellent functionalities I like to point out:

  • You can set up your data table to accept single-choice or multiple choices. You can also use this component to display data when you set it up as View Only. The single choice is in the output variable First Selected Row, and you don’t have to loop to get to the individual column/field values. One UI limitation is that the user cannot deselect after selecting a row in the Datatable.
  • You can rename the column header labels. Many fields have field names that don’t make great headers. Change them. You can use emojis in header labels as well.
  • You can set columns to Wrap the overflowing Text or Clip it.
  • You cannot allow the user to edit the values in the Datatable. For that, you still need the UnofficialSF Datatable component. If you are okay with having the user edit each record separately on a different screen, you can cycle through detail screens after the selection.

This component is an excellent addition to the Flow Builder.

If you want to learn more about the Salesforce Flow Datatable component, check out this Salesforce page.

This post was originally made to LinkedIn on July 3rd, 2023.

Read the previous post: HTTP Callout and Screen Flows

Read the popular post: One Big Record-Triggered Flow or Multiple?


HTTP Callout and Screen Flows

FlowFest v5

Last week I judged for the fifth FlowFest. I cannot believe we have five FlowFests behind us. The challenges were extra difficult this time. Two functionalities that came up repeatedly were the HTTP Callout and the data table component.

I will write about these topics.

You may remember. I wrote about the HTTP Callout GET method when it came out in beta. Now this functionality is in GA. Read the blog post here and watch the YouTube recording here. It shows you how to build a flow that can check the validity of a phone number.

GET functionality is limited. If you want to harness HTTP Callout’s full power, you need the POST method. POST is now available in beta as of the last release. You can find my previous post about how to build an HTTP Callout to shorten long URLs here.

Read the three-part blog series here.

I thank all the organizers, sponsors, judges, and participants of FlowFest.

This post was originally made to LinkedIn on July 14th, 2023.

Read the previous post: What Can Flow-Builders Do With Pen and Paper?


How to Build a Screen Flow to Complete Virtual Standup on Slack

The other day I wondered whether I could use screen flow in Slack functionality to record virtual standup updates.

Many of us are organizing our agile development work using our Salesforce Orgs.

I built a demo to do just that.

Demo Idea

The idea is to send a Salesforce screen flow to all relevant users every day at the same time. Upon launch, the screen flow will ask the user a few simple questions and record the update for the day in a custom object record called standup. Then when a standup record is created, another flow picks up the process and sends that update to a dedicated standup channel in Slack. You can see a roll of updates for the standup records in that channel.

Here is how it is done:

  1. Prepare your Org for the Slack connection. Give the necessary approval both on the Salesforce side and Slack side. Create your custom object(s).
Standup Custom Object Record
  • Build a screen flow in Salesforce and mark it under advanced settings available for Slack. This will create a custom Slack action for the screen flow.
Salesforce Screen Flow
  • Create a schedule-triggered flow to run every day at the same time and call the custom Slack action.
Schedule-Triggered Flow Calling the Custom Slack Action
The Notification the Slack User Receives Every Day
Screen Flow Displayed in Slack
  • Build a record-triggered flow to trigger on create and post the update to the dedicated Slack channel.

See my additional screenshots below.

Additional Screenshots

Create Records Element for the Standup Custom Record
Slack Message Action Posting the Standup to the Dedicated Slack Channel
Custom Slack Action Calling the Screen Flow

This post was originally made to LinkedIn on June 28th, 2023.

Read the previous post: One Big Record-Triggered Flow or Multiple?

Read the popular post: Slack and Flows – Salesforce Flow Tips Newsletter


New Features of Summer 22 (continued)

Hello folks,

Summer 22 is arriving soon, and the second part of my quick tour is here.

In the last issue of the newsletter, I showed you a few changes that will be released soon. Let’s continue.

Screen flow enhancements:

1-Collapsible headings for sections: We received the functionality of multicolumn sections in screen flows a few releases ago, and I love them. With this release, we get a header, which makes the section collapsible.

2-Dynamic Forms (Fields – Still Beta) supports Name and Address Fields: Fields functionality is a very promising functionality that now supports Name (Salutation, First Name, Last Name) and a full Address. I don’t understand why this is still in beta, though.

3-Dynamic Forms Address automatically populates address: When you combine the new Address field with the Google Typehead functionality, you give the user the power to populate the address fields automatically.

Some other notable enhancements:

1-Orchestrations are deployable via change sets now.

2-Associated flows can be opened from within the Orchestration via a link.

3-You can order triggered Orchestrations with Flow Trigger Explorer exactly as you do with flows.

I want to add that dragging items on the Flow Trigger Explorer changes your flow’s running order parameter setting. The screen shows you a confirmation screen explaining the change.

The big news of this release is the addition of the No-Code Flow Testing (Beta), though. I am super excited about this, but I will take my time to review it before going into more detail.

I am heading to Texas Dreamin’. I will present there on the Flow Trigger Explorer and the Orchestrator. Come to my session if you will be there. If you won’t be there, no worries; I will present similar content soon virtually. Stay tuned.


P.S. Originally published on 04/26/2022.

Read the previous issue of the newsletter here.

Read the next issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.


Error Message Design in Screen Flows

Hello folks,

This week I would like to go over a few ideas about error message design in screen flows.

You probably already know that you can build fault paths coming out of various elements in flow. These paths will allow you to take a different route when the fault occurs. The inconvenient truth about these fault paths is that the flow will still generate an error email. If you are an admin with tens of these flows active or a consultant with hundreds of them running, you would not want to receive emails. So, going down the fault path is like avoiding an accident but with a scratch. Therefore you should build fault paths but preferably avoid using them.

How can you do that?

The field validation inside your screen element is your first tool to avoid errors. Remember; your screen flow is unaware of the validations you built on the object. This means that you need to create the same validations inside your flow, so that you don’t face any errors when your flow creates or updates an object record.

Your next step is to use decision elements to predict and handle all possible outcomes. Then, connect your outcomes to human-readable error messages on screen elements that allow the user to take the necessary actions.

Let me give you an example: You have a screen flow guiding the user with creating an order. And the user can select how the ordering party will pay. Among the payment choices, there is the credit card option. However, you don’t have the credit card information for some clients entered into the system. In addition, you don’t want the user to collect credit card information due to security concerns.

Following the screen that facilitates the payment method selection (a picklist), you can build a decision that checks whether the credit card information for the account is on file. You can then connect the decision outcome to a screen element that displays this message: “There is no credit card information for the account on file; please pick a different payment method.”

If you have a process that collects the credit card information from the account contact in a secure way, you can ask the user to decide and trigger that process based on the user’s selection.

If you don’t want a standalone error screen, you can mimic the validation error messages using display text components in screen flow.

How do you do that:

  1. Create an ErrorMessageTextVar resource.
  2. Create a decision after the screen subject to the error check and build the error outcome criteria: “Yes Error”
  3. Add an assignment on the “Yes Error” path and assign to the ErrorMessageTextVar an error message like “Please correct the error and resubmit.”
  4. Add a display text component on the screen where the check occurs and add ErrorMessageTextVar. You can change the color of the font to red. Remember; the message will only be displayed if the assignment occurs.
  5. Connect your assignment step to the screen element, creating a loopback for when the error condition holds true.

If you want to avoid your user having to reenter all the information, work with a record variable, assign the values of your screen components to the record variable fields, and set the default values for the screen components to the record variable field values. If done correctly, the screen will prefill the information that the user entered before the error occurred.

You can still use fault paths for the cases you cannot think of and lead them to a catch-all error screen. If you want to make sure all the database commits will be rolled back when you experience an error, use a roll-back element right before this catch-all error screen and wherever needed in your flow. 


P.S. Originally published on 02/21/2022.

Read the previous issue of the newsletter here.

Read the next issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.


Collection Filter Element in Spring 22

Hello folks,

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.


P.S. Originally published on 01/31/2022.

Read the previous issue of the newsletter here.

Read the next issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.