Developer Blog: LWC Best Practices for Screen Flows

Link: LWC Best Practices for Screen Flows

Over on the official Salesforce Developer Blog the team published a critical addition to Salesforce’s compendium of best practices knowledge. While there’s plenty of articles out there that outline LWC best practices, very few talk about LWCs within screen flows.With the upcoming Reactive Screens effort going Beta (and GA this year), it is more important than ever to understand how to handle navigation events and properly tracking changes within your custom components.

Let us know what you think in this LinkedIn post or the comments below.

From Kevin Luptowski: Tips and Use Cases for Running Screen Flows in Slack

Kevin is arguably the world leader in integrating Flow and Slack!

This post is dual-purpose: 1) to educate on how to make a screen flow available in slack and 2) to provide a downloadable example of a real world use case. 

This previous blog post ( provides exceptional detail into how Salesforce screen flows can be sent into Slack, including the required permissions and initial setup steps. This post assumes you have authorized Slack to connect with Salesforce and focuses on the flows and use cases themselves.

In short, Slack screen flows depend on _two_ flows being created: 

  • the first, the actual screen flow that serves as the modal UI for end users in slack.
    • This flow must be activated before the second flow
  • and the second, the “dispatching” flow that sends the screen flow to the Slack channel/user of your choice. 

Example Use Case and Demo Component:

If you have not yet begun to leverage Swarming in your customer service operations, it is an incredibly effective way for customer service agents to get answers faster by bringing in the right team of experts to collaborate and work toward a resolution. Rather than using chatter for that collaboration, Slack allows that team of experts to communicate in near real time in slack channels connected to Swarms, a new standard Salesforce object. 

The general premise of a swarm is simple: an agent is working on a case (or problem, incident or change request!) in Salesforce and needs help. The out of the box “Begin Swarming” flow allows the agent to create a channel in Slack directly from the Service Console, invite team members to the slack channel, and creates a Swarm and Swarm Member object(s) related to the case. The channel in slack serves as the collaborative hub for the team to solve the issue, and contains a button with the option to “Finish Swarming”. The bidirectional aspect of this scenario is unfortunately limited.  Clicking Finish Swarm merely closes the swarm object record. A subsequent Salesforce release included a second flow which would auto close the case as well; however, this process is lacking the ability for members of the slack channel to make additional edits to the case or make free text commentary to summarize their findings. 

This packaged solution aims to supplement the swarming experience by providing a more ample wrap up opportunity. It hinges upon two flows: a record triggered flow on the Swarm object that “dispatches” a separate screen flow to slack.

Upon closure of the swarm, a message is sent into the swarm channel with a button to open a screen flow. The recipient, message, and button are cofnigured within the dispatching flow. The screen flow contains multiple input fields which will then update the record related to the swarm. Once installed, the screen flow is configured to update the following fields:

  • Case
    • Status
    • Case Reason
    • Close Summary Notes (a custom field included in the package; give your users access via the Swarm Wrap Up Slack Flow permission set and add to page layout as desired)
  • Problem
    • Status
    • Root Cause Summary
  • Change Request
    • Status
    • Close Summary (a custom field included in the package; give your users access via the Swarm Wrap Up Slack Flow permission set and add to page layout as desired)
  • Incident
    • Status
    • Resolution Summary

The fields available for input and update can be configured by updating the “wrap up screen” and “update records” elements within the screen flow. See attached video. 

Pre install steps

  • Assumes you’ve enabled the slack to Salesforce integration, swarming, and your user has authenticated the service cloud for slack app

Post install steps

  • Assign “Swarm Wrap Up Slack Flow” Permission Set to swarming users so that they may edit the Case.Close Summary Notes and Change Request.Close Summary fields
    • Add these fields to page layouts if desired
  • Edit the “Swarm Wrap Up Slack Dispatching Flow” so that it points to your authenticated Slack workspace



Install Unmanaged Package

Working with Remote Site Settings

Some Flow extensions use Salesforce public API’s. They basically go out from your org, into the Internet, and then back into Salesforce. When they do this, they run into some of the web security that Salesforce uses to protect your org. These registrations are called Remote Site Setting. For API’s on the public surface of your org, you have to register the URL of your own org onto your org. (If this sounds strange, you’re not alone.)

If you haven’t done this and you try to run a Flow with an extension that uses these apis, you’ll see an error. Here are a couple of examples of how this error might show up:

To address this, copy the initial part of the endpoint in the error message to the clipboard. in the example above on the right, that would be


To address this, copy the root url from the error message and go to Setup –> Remote Site Settings. Create a new setting and paste the URL there:

This configures your org to essentially allow applications to run that call out to the internet and then back into the same org via its api endpoints.

‘Analyze Flows’ Compares Two Flow Versions and Reports on the Differences

For a long time, we’ve wanted to address the manageability gap that Flow has regarding version control: There has never been a practical way to compare two versions. This new Flow application provides a set of comparison tools.

Here’s an example of the kind of report that gets generated when two versions are compared:

The initial release includes several useful analysis modules, but hopefully that’s just the start. Analyze Flows is designed as a framework so that additional analysis plugins can be added to it. Right now, it doesn’t have 100% coverage for all possible changes, but if there’s interest in this, we should be able to keep adding coverage.

To use the Analyze Flows tool, install this package, and run the Analyze Flows flow. Select two versions of the same flow. As an example, we’ll analyze this flow:

Let’s compare version 3 to version 2:

Note that you need to set up a Remote Site Setting to authorize Flow to make use of your org’s external API’s.

Here’s the report that’s generated:

The report points out that an Update Record element called Update Case was removed. Let’s visually verify that. Here’s version 2 and version 3, side by side:

Now let’s compare version 3 to version 4:

There are a couple of new Assignment elements. Let’s run the analysis:

There’s a bunch of information here:

  1. The first two rows report the presence of two completely new Assignment elements. These are the ones in the red box, above.
  2. The next three rows, however, refer to a different element. It’s also an Assignment element, but it’s the one called ‘Assign to Variable:

This ‘Assign to Variable’ element is present in both Version 3 and Version 4. However, it’s configuration has changed. And here some of the power of Analyze Flows is displayed. The fifth line of our report draws attention to an ‘AssignmentItem’ that now has a value of 67. This turns out to be the right-hand-side of one of the Assignment Rows. Let’s compare version 3 and version 4, but focus on the property editor of that one element:

In V1, this configuration-level comparison is supported for: Create Records, Delete Records, Update Records, Screen, Action, Start, Subflow, Decision, Assignment

Not Yet Supported

Wait, Loop, Formula, Choice, Text Template, Steps and Stages (Orchestration), Process Metadata Values, Rollback Records


Note: this requires version 3.12+ of Actions Base Pack and version 3.0.18+ of Screen Components Base Pack

V 1.0.1 1/18/23 Production Sandbox Requires version 3.12+ of Actions Base Pack. Fixes the ‘Apex Type not found’ bugs


view source

Old Releases

V 1.0 1/10/23 Production Sandbox Initial Release

Developer Notes

Dual Flow Version Selector Screen Component

This new lwc enables the selection of two specific versions of two flows:

It returns the names of the selected flows. Note that it appends the selected version number to the apiName, like this: Test_Flow-1. This is how you request a particular version when retrieving Flow metadata.

It’s available for reuse.

Tutorials for the New ‘Action Builder’ (HTTP Callout) in Flow Spring ’23

Check out these early introductions from Josh Dayment, Andy Utkan, and Daryl Moon. This is a truly disruptive feature because every time someone makes a new Action using the official HTTP Callout tool, it generates a piece of External Service metadata that’s packageable and redistributable. So, for example, if 3 or 4 of the Flowhana get together on a Friday afternoon and divide up the, say, JIRA API, and generate actions for all of its calls, the results can be put in a package that can be put on App Exchange and installed anywhere.

From Andy and Josh:

From Drive Connect: Automate the Creation of Google Drive Folders using Salesforce Flow

Editor’s Note: UnofficialSF is pleased to enable commercial creators of Flow extensions like Drive Connect to introduce their products and demonstrate useful use cases. One of our goals is to see a rich tier of commercial solutions in addition to the many free extensions that will continue to be available.

Content provided by Drive Connect

Drive Connect leverages Salesforce flows to automate the creation of files and folders in Google Drive and associate them to the appropriate Salesforce records by storing their url links as content version records. Now users can create intricate folder structures within seconds rather than wasting time in Google Drive, without any code!

Drive Connect was built to work natively in Salesforce. The Automate Drive Flow action has a custom property editor that simplifies the process of building your Drive operations. Some common use cases include:

  • Automating the creation of folders for your accounts upon record creation, then creating folders for the opportunities that will live under the account folder
  • Automation of quotes, orders, or proposals using our merge field based templates on Opportunity Closed Won stage
  • Linking existing account folders to new opportunities upon record creation

Understanding Automate Drive Options

The Automate Drive action allows you to execute a wide variety of functions from Salesforce. Drive Connect requires a record ID to know what is the record initiating the operations, and the most common means of getting this ID is to trigger the flow via a record change. Multiple actions can be built to execute in a specific sequence and hierarchically all from within the custom property editor. Let’s get familiar with what each operation does at a high level.

  • New Drive Folder – The ability to create new folders in Google Drive. You are able to leverage native Salesforce merge fields to create custom folder names (example: you can create a folder with the same name as the record triggering your flow). You are also able to choose the destination of where the folders will live in Google Drive. 
  • New Folder Link – Link an existing folder from either a lookup relationship on the object or from selecting a folder in Google Drive
  • New File Link – Link an existing file from either a lookup relationship on the object or from selecting a file from your Google Drive.
  • Update Drive Folder – Choose a folder to update the name or the location of. This is useful when you want to move an opportunity folder to a different location once the stage has hit Closed Won or Closed Lost.
  • Update Drive File – Choose a file to update the name or location of.
  • New File from Template – This operation will generate a document leveraging Drive Connect’s document generation functionality. You’ll need to choose a template, the file format it will be formatted as (PDF, Google format, or Microsoft equivalent), and the resulting file will be created in Google Drive.

Additionally, you can add child operations to many of the operations listed above without having to add a new flow action. Examples of these are:

  • Save a copy of the file to Salesforce
  • Create a shortcut of the file in a different location
  • Link the file to a parent record via lookup relationships
  • Update a field on the record with either an ID or URL of your choice

Take a look at our help documentation for a full overview of our drive operations.

Use Case Example 1: Automatic Folder Creation for Accounts and Opportunities Based on the Stage field.

Let’s take a look at a common use case where a Salesforce org needs proper naming conventions for their Google Drive folders for Accounts and Opportunities. Everyone is familiar with a cluttered and unorganized drive, thankfully Drive Connect can provide order to how your folders are structured so employees can always find what they are looking for.

First off, you’ll need to install the Drive Connect app. We offer a 14 day free trial so you can set up this entire automation and see it in action before purchasing. 

Alright, let’s move on to our first use case. MarvelPoint Real Estate is using Salesforce to keep track of its sales pipeline. Currently the sales team is manually creating folders for their accounts in a “Clients” folder in a shared drive. When a new opportunity arises, they manually create a folder in Google Drive under that account. Ideally the name of that folder is the same as the Opportunity name.  

In this opportunity folder, 2 folders need to be created. One is for “Legal” and one is for “Pictures”. 

In order to keep track of the right folder in Salesforce, they created a custom URL field on the object. The salesperson needs to remember to copy the Drive Folder URL and paste it into the field, otherwise there would be 0 connection between the two systems.

This needed to be done for every Account that was created in Salesforce and is a tedious task to do manually. MarvelPoint was seeking a better way in organizing their folders and files as the team often forgot to create the folders in the right naming structure, which led to duplicate folders.

This is where Drive Connect and Salesforce Flows come into play. MarvelPoint wants to create a flow that will automate the creation of their folders.

The first thing they do is create a new flow. Since MarvelPoint wants to create a new folder for all new accounts being created, let’s start there.

Drive Connect leverages Record Triggered Flows in Salesforce to run automations.

Let’s choose the Account object to trigger this flow. Since MarvelPoint wants folders to be created for all new accounts created, let’s leave the other options as default.

Next, we will add an action and search for the Automate Drive action. For this flow, we will use the New Drive Folder action. Here we will create a folder using the account name. You can select a field from the Account object or one that is related to the account object via lookup.

Next, we will choose a destination for the folders to live under. MarvelPoint desired to place their account folders under a shared drive called “Clients”.

Linking the folder to the record simply requires you to check the checkbox. We’ll also want to upload files to this folder so checking it as the default record folder will have any new files and folders created from that record default to live under that folder.

An additional request from MarvelPoint was to create an “Opportunities” folder under this account folder to house all of their opportunities. In order to do so, a child operation must be created under the folder we just created where you will use the New Drive Folder operation again. Multiple child folders can be created under a parent folder and child folders can even be created under those child folders if desired.

Here is a demo video showing you how to set up a similar flow we just described.

Alright, so we’ve completed our folder structure for the accounts folder. Once that’s activated, we can go ahead and create another flow for our Opportunities.

Use Case Example 2: Creating and Linking a Child Folder Conditionally

This use case will behave similarly to the last, but the stipulation for this flow is that we only want to create a folder if the stage has hit “Qualification” as Marvelpoint does not want to create folders for unqualified records. We also only want this to run once so we should only allow the flow to run when the record is updated to meet this specific condition.

Now let’s add an Automate Drive action. We will create a New Drive Folder with the name of the opportunity using a merge field. We want the destination of this folder to live under the Account folder’s subfolder called “Opportunities”, so we will choose the option “Folder in Parent Record’s Default Record Folder”. Next we need to choose which lookup field from the opportunity record to be the parent folder, which in this case is the account lookup field. Then we will type in the name of the subfolder, which is “Opportunities”.  

We will also create two child folders, one named “legal” and one named “photos”. 

Use Case Example 3: Creating a Document in a Folder

Finally, let’s create a child operation under the legal folder and place a document in it. The action we will choose is the File from Template option. From here we will choose a template from our templates folder that can be created using Drive Connect’s Document Generation technology. We will create an NDA document as part of this automation. This document will live in the legal folder as every opportunity will need its own NDA. 

That’s all that MarvelPoint needs to get their sales team going so let’s save and activate this flow as well.

Now that our flows are activated, let’s see it in action. First, let’s create a new account. Once the account is created, we’ll see the Google Drive folder with the name of the account linked to the record. 

When clicking on the folder, notice that our “Opportunities” folder lives within it.

If we create an Opportunity record in Salesforce and change the status to “Qualified”, we’ll see files and folders created in Google Drive. 

Clicking on the folder will show you your subfolders and if we click on the legal folder, you’ll see the NDA document in there and ready to be sent off.

Now MarvelPoint’s sales people will never be confused about where to upload their documents when working on their deals. On top of that, MarvelPoint is experiencing significant cost savings since they moved all their files to Google Drive from Salesforce.

Learn more about DriveConnect at, or check out our AppExchange listing! We offer a 14 day free trial of the app, no credit card required.

From Andy Haas: A high-volume Convert CSV To Records screen component

If you want to import a CSV file, you can use this existing invocable action. It has a good feature set, but there are some limits on the file size that can be imported that stem from backend Salesforce limits. Andy Haas has provide a complementary Flow Screen Component that also allows CSV imports. This version processes files on your local computer, and can work with larger files. This component will automatically navigate to the next screen when the parsing has been completed.

Use Cases

The CFO at a large company has come to you with a request to allow end users to import a CSV file from their merchant companies each month. He doesn’t want to have to call you each month or learn another platform to import these records. He tells you that they partner with many different merchant processor companies and the files will stay the same each month; he wants the process to be as simple as possible for the end users. You ask him for the CSV files to create an object and fields corresponding to the file.

You sit down, open the CSV file the CFO sent to you, and create the object with the appropriate fields. You then open up a new Screenflow, drag the Convert CSV to Records – LWC Version to the screen, and set up the component’s configuration. 

After you have set up the component, you test drive it out and see how quick and simple this will be. You schedule a meeting with the CFO and show him the progress; he is amazed at how well this works.

In the above use case, we talked about utilizing the component for a monthly import that the CFO has to do; this can also be used with a one-time import or a multitude of different use cases where the user is importing a file. If a user is not initiating the import, the existing invocable action will be the correct action to use. 


Add the Convert CSV to Records – LWC to the screen.


The inputs consist of 4 required inputs and a large list of optional advanced features. The underlying PapaParse library provides advanced features and is documented in the PapaParse documentation.

Input NameDefault ValueDescription
API NameThe name of the component.
Input ObjectThis is used to get the field definition.
File Import LabelThe label for the file input field.
Auto Navigate NextIf true, the flow will automatically navigate to the next screen after the component has been initialized.
Delimeter,The delimiting character. Leave blank to auto-detect from a list of most common delimiters, or any values passed in through delimitersToGuess.
New LineThe newline sequence. Leave blank to auto-detect. It must be one of \r, \n, or \r\n.
Quote Character"The character used to quote fields. The quoting of all fields is not mandatory. Any field which is not quoted will be correctly read.
Escape Character"The character used to escape the quote character within a field. 
Transform HeaderA function to apply on each header. The function receives the header as its first argument and the index as second.
Dynamic TypingIf true, numeric and boolean data will be converted to their type instead of remaining strings.
EncodingUTF-8The encoding to use when opening local files. If specified, it must be a value supported by the FileReader API.
CommentsA string that indicates a comment (for example, # or //). When Papa encounters a line starting with this string, it will skip the line.
Fast ModeFast mode speeds up parsing significantly for large inputs. However, it only works when the input has no quoted fields. Fast mode will automatically be enabled if no ” characters appear in the input.
TransformA function to apply on each value. The function receives the value as its first argument and the column number or header name when enabled as its second argument. The return value of the function will replace the value it received. The transform function is applied before dynamicTyping.
Delimiters to GuessAn array of delimiters to guess from if the delimiter option is not set.

For further details on the input values, please visit the PapaParse Documentation.

Please note that the following PapaParse inputs will be set within the component and can not be changed. Keep this in mind if any conflicting inputs will error out.

PapaParse NameValueDescription
HeaderTRUEThe first row of parsed data will be interpreted as field names.
Skip Empty LinesTRUELines that are completely empty (those which evaluate to an empty string) will be skipped.

Column Headers

The header columns are compared against the objects fields, and if the header column is a custom field and the header isn’t labeled that way, the component will rename the header and assign the custom field.


Input Object: Account

CSV Headers: Name, Description, Active

The component will convert the above CSV Headers to the following:

Name, Description, Active__c


Output NameAPI NameDescription
Parsed ResultsoutputValueAn sObject of the parsed results.
Is ErrorisErrorWill be marked true if an error has occurred when attempting to parse the CSV file.
Error MessageerrorMessageWill output the value of the error that had occurred.


Implementing this component can be as simple as creating records right after parsing like so:

Or you can be more complex with loops and filters as the output is an SObject allowing manipulation of the imported data.

With Spring ‘23 and the added ability for reactive screens, you can use this component to preview the data uploaded before creating records.

Install Link


V1.0.1 1/14/23 Production Sandbox Fixed setting the selected object in CPE

Old Versions

V1.0 12/29/22 Production Sandbox 1st version hosted on FlowComponents


View Source

Process approvals using a screen flow in Slack

With the Spring 23 release, screen flows in Slack will be generally available. I set out to explore one use case.

Approvals in Slack are currently possible but have some limitations

  1. It is only available with the Salesforce for Slack app but not available if you setup one of the cloud specific apps (Sales cloud for Slack, Service cloud for Slack etc.)
  2. You can only approve or reject but cannot add an approval comment.

I wanted to see if I can improve on that by using a screen flow in Slack. This blog will not cover the initial setup and connection of Salesforce to Slack. You can find details on how to do this in the official documentation.

My solution was inspired by two blogs

  1. Alex Edelstein created an invocable action for processing approval requests that includes sending an approval comment
  2. Yumi Ibrahimzade demonstrated how to copy an approval comment from the approval history related list to a field on the record

In order to send a screen flow to Slack you have to create two separate flows that will work together.

  1. A screen flow – this is what will surface to the user in Slack and process the user inputs there. This flow has to be marked as available in Slack. Marking a flow as ‘Available in Slack’ generates a separate ‘launcher’ invocable action that can be used in other flows
  2. A record triggered flow – This flow will act as a dispatcher and will use the launcher action, we created in step 1, to send the screen flow to Slack when record conditions are met. Slack actions can only be processed asynchronously, after the record is saved.

To test this, I setup a simple one step approval process, with simple actions that update an approval status picklist field on the record

I then created my screen flow which has only one screen. The screen displays an approval request to the user, along with some record details, and captures the responses. The flow will then use those responses to process the approval using the invocable action, and update the record with the approval comment. The flow has some input variables that will get their value from the dispatching flow. I marked this screen flow as available in Slack. I was not successful in passing a record link to the screen flow. Slack uses a special markup language to format links, which works well when sending a Slack message using the “Send Slack Message” core flow action, but it did not work when sending in the screen flow action.

The next step was to create the record triggered flow that will send to Slack. My trigger was based on a custom Approval status field set to submitted, when a user will submit the record for approval. This will work well for a single step approval process but if you have a multi step process, additional conditions may be needed to determine the current approval step. This flow gets the most recent approval process instance, work item, and approver userId for the triggering record and passes this information, along with the record Id, to the screen flow action.

When both flows are combined, I was able to send an approval request to Slack, process the response, and update the record with the most recent approval comment. Here is a short video of the complete process.

This is a simple use case for a single step approval process with a single approver. It can be enhanced to handle more complex approval processes.

  1. If there are multiple approvers, the dispatching flow will need to get a collection of all the work items and loop through to send the screen flow to all of them.
  2. If a queue is set as the approver, the the dispatching flow will need to get a collection of all members of the queue to find their userId 
  3. The screen flow can be updated to add a recall action

New SendBetterEmail Release Fixes Some Longstanding Bugs

Version 3.1 of SendBetterEmail addresses these bugs:

  • If a user removes a value from CC or BCC or To in the custom property editor, it causes sending to fail at run-time.
  • sendBetterEmail will not send multiple email addresses to CC either as string or as collection of strings in current release

Install here.

From Common-Unite: A powerful Screen Component Builder

Editor’s Note: UnofficialSF is pleased to enable commercial creators of Flow extensions like Common-Unite to introduce their products and demonstrate useful use cases. One of our goals is to see a rich tier of commercial solutions in addition to the many free extensions that will continue to be available.

Content provided by Common-Unite

The Flow Took Kit (Form and Table Builder) app is a 100% Salesforce native tool that enables you and your team to create custom Flow Screen components declaratively, with clicks, not code. These custom components leverage the power of Flow, instead of Apex, to control your component’s processes and actions. By combining Flow and the Flow Tool Kit, your team can create advanced interfaces, forms, surveys, or wizards for both internal and external users. Reducing your team’s development time, cost, or reliance on external form builder solutions.

What sets the Flow Tool Kit apart?

The Flow Tool Kit is 100% built to leverage the power of Salesforce Flow. Our custom components and features, such as live formula recalculation, modular/reusable components, and the Form (Repeater), will allow your team to move out of custom code and into a declarative Flow solution. The Flow Tool Kit is built upon the idea of modular components. Just like LWC’s or Visualforce Components, we provide your team with tools to create modular, reusable Flow Screen components. These components are configured within a custom interface outside of Flow, which allows for the decoupling of complex Flow logic from ever-changing front-end design requirements. This means that System Admins or Super Users without Flow proficiency can own and manage components without ever needing to open or edit a Flow.

Build Modular/Reusable Flow Screen Components

There is a concept that developers adhere to when writing code “Don’t Repeat Yourself” (DRY). The idea is simple, try not to duplicate code. Instead, write it once and ensure that other solutions can reference and reuse the same code if needed. With this principle, when a change needs to be made, a developer only has to update the code in one place instead of multiple locations. This reduces both initial development time, as well as future administration. We love Flow, and Flow provides tools such as subflows and invocable flows to allow logic and processes to be reused. However, when considering Flow Screens, no standard feature is provided to reduce duplicated form design and visibility logic. This often leads to duplicative configuration. This is administrative debt!

The Flow Tool Kit enables your team to create modular/reusable Flow screen components with clicks, not code. Each component contains its own set of fields, styling, and conditional logic. Admins and Developers can add these components to one or many flow screens. If something in your business logic changes, update the component, and all Flows that reference your component are instantly updated, Magic! Furthermore, our form components can be reused throughout the Flow Took Kit. Please look at our Form (Repeater) and Form (Table) elements, as well as our Shopping Cart and Survey extensions.

Decouple complex back-end processes from fluid front-end design

Everything is moving to Flow, but Flow sometimes does require a developer’s eye to design and maintain efficient back-end business processes. With the Flow Tool Kit, we decouple the front-end UX from the complex back-end processes handled by Flow. This means that your team can pass the task of field arrangement, styling, customizing labels, and other ever-changing front-end requirements to System Admins that do not currently have the skill set needed to manage a Flow. This pattern is equivalent to how Developers implement fieldsets within Visualforce and Lightning Components.

Leverage the power of Salesforce Flow

The Flow Tool Kit was designed to leverage the power of Flow. With Salesforce Flow, your team will have few, if any, limits when it comes to building out complex solutions. If you do find a limit, Flow can be extended with custom code to handle your unique business requirements.

Salesforce Flow is powerful when it comes to pre-processing and post-process handling. However, Flow has many gaps when working with Flow screen solutions. These gaps are what the Flow Tool Kit (Form and Table Builder) app was designed to fill.

Key Features | Flow Tool Kit (Form and Table Builder)

Form Builder Interface

The Form Builder Interface is a standalone app where users create custom Flow Screen components. The interface includes a live preview window that is always visible. Each change updates the live preview so your Users can see what their component will look like when dropped into a Flow. Adding input fields to your component is equivalent to the new GA Flow Fields feature within a Flow screen. Add the field to your component, and the fields data-type, label, help-text, and requiredness are loaded as your starting point. Unlike the Flow Fields feature, you can override the system defaults with custom labels, help text, prompt messages, requiredness, and more. The fields added to your component stay synced with the field’s API names. Therefore there is no need for field mapping within the Flow.

Try the Form Builder Interface!

Key Field Override Features

  • Display Picklist fields as Radio Options or Radio Buttons (define the number of columns)
  • Display Multiselect Picklist as Multiselect Checkboxes (define the number of columns)
  • Display Boolean/Checkbox Fields as Picklist and provide alternative labels such as: “Active, Inactive,” “Yes, No,” “Valid, Invalid,” etc.
  • Override default Labels
  • Append and Prepend Text
  • Change the Label’s Position (Stacked, Inline, or Hidden)
  • Add Placeholder Text
  • Add or Override Inline Help Text
  • Disable/Hide Inline Help Text
  • Require or Disable Input Field
  • Min and Max length for Text Inputs
  • Min and Max Values for Date, DateTime, Time, and Number fields
  • Set the Height of RichText and TextArea Fields

Each form component can be styled with custom themes. Conditional logic is also configured and packaged within your custom form components. Conditional logic is used to show, hide, require or disable fields and sections within your component. Conditional logic is triggered via field updates and/or pre-filling input fields within Flow Builder. See how it works.

Live Formula Field Recalculation

Form Components can include and display the values of calculated Formula Fields. These formulas can also be configured to recalculate in real time within your Flow screen. As users change field values, your formulas will be recalculated, displaying the updated result. Use these formula results to trigger conditional logic, hiding and/or showing fields and sections based on the updated formula value.

Table Builder Interface

The Table Builder Interface functions just like the Form Builder Interface. Declaratively add and arrange table columns, override header labels, and customize display properties. As you make changes, the table is updated within the preview window, allowing you to track how your table will look within a flow.

Try the Table Builder Interface!

Table components can be reused within multiple flows. Simply add your table component to a flow screen and pass in a record collection to populate the rows. Within Flow, you define how Users interact with the table records by enabling users to create, update, select or delete records. Adding or updating records within a table functions like a quick action on a standard record page. Admins pass in Form components to the table, as well as an optional pre-fill record template. When a user clicks the “New” or “Edit” button, a modal opens, displaying the fields defined within the form component. Users can edit field values for a record even if not displayed as a table column. Tables can also be configured to display as a hierarchy tree.

Flow Screen Components and Flow Actions

Modular form components, built with the Form and Table Builder interfaces, can be weaved together with standard flow screen components and custom and third-party components to create advanced forms and interfaces.


The “Form” screen component is what an administrator uses to add form components to Flow screens. Our form screen components communicate, passing field and visibility updates between components. This allows you to easily weave together components across objects as well as standard and custom Flow screen components. The custom property editor allows admins to assign record type options, hide headers, override the theme, or collapse form sections within accordions.

Dynamic Form Component Assignments

Form Components can be explicitly added to a Flow screen with a “hard-coded” reference. Alternatively, Form Components can be assigned to your Flow screens dynamically. This is powerful! Consider our free Survey extension app. We leverage a single Flow, with one screen, to handle and create Survey_Reponse__c records. We pass into our Flow a Campaign Id. The related Campaign stores a reference to a Survey form component. Each Survey component can be configured with custom Survey questions and branding. This allows us to dynamically change the fields displayed within the Flow based on the related Campaign. Allowing a single Flow screen to handle an unlimited combination of survey questions. This pattern, “Data-driven screen flows,” is a recommended best practice. Check out this UnofficialSF article for additional considerations: Scaling to Thousands of Screens with Lightning Flow.

Form (Repeater)

The Form (Repeater) component allows users to create and/or edit multiple records within a single Flow screen. Admins can pass a form component to the (Repeater) and a collection of records if the component requires a pre-filled form. Users can then add more records by clicking the ‘New’ button. The repeater adds a new record to the screen with the same input fields packaged within the form component. In addition, admins can customize the repeater within flow screens by enabling a User to Create, Clone, Select or Delete records within the repeater.

Form (Buttons)

The custom buttons within the Flow Tool Kit allow you to configure as many buttons as your solution requires within a single Flow screen. Easily customize each button’s label, icon, branding, or action with our intuitive property editors. Confirmation modals can also be enabled for any button. When enabled, the user is presented with a custom message and a confirmation button that must be clicked to move the Flow forward. Additionally, buttons can be configured to bypass field validation as well as trigger Google reCaptcha validation. You also control how and where your buttons are displayed, such as within docked footers or grouped drop-down menus.

See Also:

Simplify complex Flow solutions

Reduce Loops

Loops add complexity to flows and can degrade the user experience. Therefore, the Flow Tool Kit includes two features, the Form (Repeater) and Form (Table), which allow users to add, update, delete or select multiple records within a single flow screen. These components return output collections (e.g., Insert Collection, Update Collection, Delete Collection, Selected Collection). As a User interacts with records within these components, the records are sorted and added to the appropriate output collections. These output collections could then be passed right into DML elements (Create, Update, Delete) within your Flow. You can also predefine field values for new records created within these components with a record template. This is useful for setting values such as RecordTypeId or related lookup Ids that should apply to all new records.

Eliminate Field Mappings

Form Components maintain a direct reference to your Object schema. This allows your field labels, help text, picklist values, and field API names to stay in sync with your object. Changes made are instantly visible within your Form Components and the Flows that reference them. This also means that there is no need for field mappings within your Flow. Instead, our Form Components pass back a “record” variable with all field values added or updated by your users mapped to the referenced field API names. Simply pass this “record” output into a DML element for processing. For some Flow solutions, this could mean most changes happen within the Form Builder with no need to open and update the related Flows, just like Field Sets. Magic!

Next Steps

Try out the latest release of the Flow Tool Kit by visiting our site or through the AppExchange. We have two versions of the Flow Tool Kit, “Free” and “Unlimited.” The Free version includes all features but will limit your org to the following objects: Account, Contact, Case, Lead, and our custom Survey object. The Unlimited version is sold as an org-wide license and allows for any object Custom or Standard. Nonprofits with ten Users or fewer can purchase the Unlimited license for $30 per month. All other orgs can purchase the Unlimited license for $150 per org per month. You can contact us for custom pricing considerations. Visit our Vimeo showcase for how-to videos and demos.

Follow us on LinkedIn for product updates and demos. Or contact with any questions.