Summer ’24 Feature Deep Dive: Create Richer Screen Flows with Action Buttons (Beta) | Be Release Ready

Summer ’24 is just around the corner! Discover Action Buttons, one of the new screen flow capabilities I’m really excited about, and check out Be Release Ready for additional resources to help you prepare for Summer ’24.

Screen Actions are a screen flow game changer

One of the most important new screen flow capabilities is now here: Action Buttons! You can now add an Action Button component to a screen to run what we call Screen Actions that can retrieve or crunch data and then makes the data available in that same screen for other components to use. This unlocks the true power of reactivity to let you create truly dynamic single-page applications. 

Let’s take a deep dive into one of my favorite features ever to come to screen flows (though I am admittedly biased!).

Use Screen Actions to keep users on the same screen

When would you use a Screen Action? If you want to keep users on a single screen, Action Buttons are your ticket.

Let’s take a classic use case where you select an account, and from there, you generate a list of contacts based on that Account (or Accounts), and then get more information about a selected contact. You can do that with an Action Button.

In the example below, we have a single flow serving as an underlying data broker for the screen. Each of the Action Buttons on the screen calls on the same autolaunched flow for the data that it needs, powering any components that need it. For you developers out there, think of this as your Apex controller, except you don’t need to write any code.

Set up an Action Button

Setting up an Action Button is straightforward, especially for those of you who have created a subflow before. 

Let’s dive in. At a high level, you can see the process we follow in the below diagram.

1. Plan your screen and Screen Action(s)

Think about what you want your screen to do and how your Screen Action will help you create that bigger, cooler, amazing dynamic screen. What inputs do you send to your Screen Action from the screen? Are there any existing autolaunched flows you could use?

For example, imagine you want to do a few things on your screen. You want a user to select one or multiple contacts from a lookup and get contact roles for the opportunity as well as some basic information about that opportunity. In that same screen, perhaps in a separate Action Button, you also want to see the account’s other opportunities in a Data Table component.

Here’s what your autolaunched flow would need to receive from or send to the parent screen flow.

• Input:
  • A list of account IDs: This will be an accountIds text collection value that we get from a Lookup component. We will use it to retrieve the entire set of opportunities and contacts for a given list of accounts. 
• Outputs:
  • Contact records
  • Opportunity record

2. Create or reuse your action (autolaunched) flow

This process should be familiar to anybody who’s made a subflow—in fact, it is the same!

• Perform the actions you want in your autolaunched flow, like a Get Records, a Loop, or an Invocable Action.
• Create variables for any data that you want passed into the autolaunched flow by marking them as ‘Available for Input’. This ensures you can pass data from your screen components into your autolaunched flow. 
• Next, create variables for the data you want to come back into the screen flow and mark them as ‘Available for Output’. Below is an example, but take note of the naming here. I like to start the names of variables with ‘output’ or ‘input’ to make things cleaner.

• Assign the results you want returned back into your screen flow in an Assignment element to the resources you’ve marked as ‘Available for output’. This would be things like Get Records, Apex Actions, a Transform result, or a Collection Filter element.

• Save, test, and activate your autolaunched flow. If you can debug/test it by itself, I’d recommend doing that first. The autolaunched flow must be active to appear in the Action Button’s flow selector.

3. Set up your Action Button

• Select the Action Button component from the component palette, provide an API Name and Label for the Action Button, and select the autolaunched flow we just saved, tested, and activated. 
• From here on the experience is identical to setting up a subflow! Map the screen components to your autolaunch flow’s input variables and check out the fancy new ‘View Output Resources’ pane that has a list of all of the Screen Action’s outputs.

4. Use the Screen Action results anywhere on the screen

• Now that you’ve set up the Action Button, you can reference the results by finding the API Name of the Screen Action triggered by the button and drilling into ‘Results’, then finding the output you want from the flow that ran.
• In the below example, I set up a Data Table component with contact records that were the output results from the Action Button. 

Note: In some cases, like when you’re creating a collection choice set as a choice option, for the action results to appear in the screen editor, you may need to first save your Screen element by clicking Done in the screen editor before the action will appear in the resource picker.

5. Profit

Run the screen flow and watch the magic happen! Combine it with conditional visibility and our new Read Only/Disabled input states and you’ve got some grade-A screen flow goodness.

More screen action examples with reactive choice options 

We’ve also made the underlying infrastructure of choice options more dynamic with reactive collection choice sets. Now, when the underlying collection of a collection choice set changes, the options will change as well automatically! This opens up a ton of brand new use cases that were previously accessible only with code and pair wonderfully with Screen Actions.

Dependent picklists as records

Use cases for screen Action Buttons extend well beyond the basic data table example above. As part of Summer ’24, collection choice sets are now reactive, which means you can also dynamically generate choice options within things like radio buttons and choice lookup! This means you’ll be able to create what we call ‘DIY dependent picklists’ that are based on record data.

Imagine you have a university application where you select a major (stored as records) and concentrations (stored as records that are related to Majors). With screen actions and reactive record choice sets, you can now keep users on the same screen when selecting both a major and a concentration. 

Filtering the records in a lookup

For years, the community has asked for better record filtering with the screen Lookup component. Unfortunately, we won’t be directly delivering that, but I think we are inching ever closer with the Choice Lookup component as a viable alternative. In some cases, this may be an even better solution. As a refresher, the Choice Lookup component lets you provide a collection of records as your source data and have users select a record in a similar experience as the Lookup component. Before Summer ’24, that list of available records was static upon entering the screen. With reactive choice options and screen actions, you can now generate lookup options specific to the actions taken by the user on the same screen. 

Think about that for a moment. What’s powerful here is that you can go well beyond basic formulas that exist in a lookup filter. You can perform callouts, traverse deep into relationships, or retrieve unrelated records and use those records as the source data for your Choice Lookup component. Need to generate a list of contacts with high-priority cases based on an account selected in the same screen? Go for it!

Creating scalable Screen Actions

I’d like to take a moment to generalize how I think people should be thinking about these screen actions. Think about what reusable jobs you want your action flows, or subflows, to perform. I suggest creating a set of ‘utility flows’ that perform frequent operations.

Some examples of reusable flows:

• Takes a recordId, looks at it, determines the right object, and returns the entire record and any key related records, such as an account record and all of its contacts, opportunities, or cases
• Takes the selections from a multi-select checkbox (a semi-colon delimited text variable), parses it, and converts the selection to records

On top of reusing autolaunched flows, you may also want to consider scenarios where a single autolaunched flow handles all of the work for a single screen in your flow (or all of your screens depending on how complex it is). 

Take, for example, this scenario where there are two Action Buttons on a screen: one button to retrieve the contacts for a set of selected accounts with specific criteria, and another to get the contact record and its high-priority open cases.

Because of the extra filtering requirements, it might not make sense to reuse your utility flows. You could build two individual flows for each button, but that might be hard to manage. Instead, create a single flow that both buttons can launch. 

In the below flow, we use one autolaunched flow to get contacts and contact cases, and retrieve the entire contact record that we can use throughout the screen.

Notice that we can use the above flow for two different buttons on the same screen. The only difference between the two is the inputs into the action. 

Notice how we use the same autolaunched flow but use different inputs for the two buttons. This allows us to make things nice and tidy, keeping the maintenance of the autolaunched flow to a minimum. While the naming here isn’t great, think about a naming convention that lets you easily tie the autolaunched flow to the screen flow. If your screen flow is called ‘Account/Contact Handle Flow’, consider naming your autolaunched flow something like ‘Account/Contact Handle Flow – Action – Get Account and Contact Info’ so they appear together when ordered alphabetically in your flow list view.

Build your flows differently when using Screen Actions in Experience Cloud sites

Here are some quick tips to make sure your Screen Actions are secure. In many ways, Screen Actions are a lot like subflows, but there are some differences in how they run. This is particularly important if you’re building a flow intended for unauthenticated users, or guest users, in Experience Cloud sites. 

Flows are executed differently when they’re run by a Subflow element versus a Screen Action. Screen Actions execute from the user’s browser, then the server. In contrast, subflows run exclusively from Salesforce’s servers. This key difference means that you need to be mindful of what goes in and out of your Screen Actions when exposing your flow to external audiences. Knowing this, let’s look at some recommendations.

• Don’t enable system context for your Screen Actions: In general, it is poor practice to use system context-enabled screen flows in Experience Cloud sites. Instead, use subflows elevated in system context that perform the operations you need between screens.

• Identify specific fields when using the Get Records element: In order to keep your data secure, we recommend retrieving the specific fields you need in a Get Records and avoid using the default ‘Automatically store all fields’ setting. This recommendation is important for unauthenticated experiences, but is also relevant to all implementations of Screen Actions. See the next section for details.

• Be selective with your inputs and outputs: Screen Actions should only be used to power components on the same screen—we don’t recommend referencing a Screen Action output outside of the screen where it is used. Only return records and fields that will be used on the screen—nothing more.

• Perform Create / Update / Delete operations outside of the screen: For better error handling and data security, we do not recommend performing anything other than queries and complex data calculations in your Screen Actions.

Improve performance by manually identifying which fields to store in the Get Records element

When you output a collection of records in a Screen Action, we recommend that you avoid using the ‘Automatically store all fields’ option in the Get Records element to prevent performance degradation and/or errors related to governor limits.

This handy setting was originally added to prevent Flow from hitting errors if you tried to reference a field that you didn’t include in your Get Records. While the Flow engine does its best to try and obtain any fields downstream in your flow, it is impossible to know which fields are needed in many scenarios.

When passing the results of a Get Records that has the ‘Automatically store all fields’ setting selected into a Lightning Web Component, like Data Table, everything the running user has access to will be pulled into your browser behind the scenes. This has big performance implications.

Think about what happens when you have an object’s worth of data stored in the browser multiple times. That is a ton of information being passed around. If, for example, you have 200 data table rows selected, any time a row selection happens, the flow runtime makes that data available elsewhere in your flow to use. The more fields you have, the more data is passed, which introduces potential for performance degradation. 

On top of browser performance limitations, there’s also a hard framework limit that prevents a single screen from being larger than 1 MB at the time of writing this article (Summer ’24). While this is difficult to calculate and track, multiple data tables loaded with records and fields can potentially trigger this limit. For the curious folks out there, you can see this limit in action by embedding a Data Table component of ContentVersion (Files) records and including the FileData field in the source data. When you select a record and navigate, you’ll hit that size limit. 

Key differences between Screen Actions and Subflows

We’re beefing up our Help docs with some of this information, but keep in mind that there are key differences in how these Screen Actions behave from a normal subflow. 

• User / system context: Screen Actions do not inherit the context of the parent flow. If your screen flow is running in system context, your action flow will not inherit system context. System context must be explicitly turned on for any Screen Action.

• Limiting flow access: If you’ve limited access to run a flow, as is required to run a flow for a guest user, you will also need to grant access to any flow run by a screen action within that flow. Subflows, conversely, inherit the access from the flow calling it and do not need special access.

• Debugging and flow versions: When debugging a screen flow, you can optionally run the latest version of any subflow. Screen Actions always run the active version.

Tips and tricks

I’d like to share some tips and tricks that all use the ‘IsSuccess’ output from every screen action that runs from a button press. You can do some pretty snazzy things with it.

Validating components based on the results of a screen action

Imagine you had some fancy Apex validating an address or an email address in your action flow. You could validate that a user typed in a valid entry by outputting a simple boolean/checkbox flag to your flow, then check that it is true in your Input Validation criteria.

AND(
{!Action_Email_Validity.IsSuccess} = true, 
{!Action_Email_Validity.Results.outputIsEmailValid} = true)

Then, mark your Email input as required, and you’re done!

By marking a component required that uses the action’s results and including the ‘isSuccess’ flag in the component’s input validation criteria, you can ensure a user will need to click the button before proceeding to the next screen.

Disabling or hiding components until an action runs

We recently added Disabled and Read Only inputs to many of our components! If you map any of these new Disabled or Read Only inputs to the ‘isSuccess’ output of a screen Action Button, you can disable an input when an action runs to prevent people from overwriting any of its values. 

On that same note, you can conditionally hide components that might use the action’s data until the action runs so users don’t see empty component data until the screen runs.

Connect with the community

We want to hear from you! We’ve created the Screen Flow Action Button Beta Trailblazer Community Group for you to describe your cool use cases, ask questions, and share feedback with the Automation product team.

Summer ’24 resources

Check out our Reactive Components Resources trailmix to learn more about reactivity through articles, blog posts, and videos from all over the Flow community.

If you want to learn more about securely sharing your Experience Cloud Sites with Guest Users, check out this help article.

Throughout Summer ’24, we’ll publish blogs and videos designed to equip you with the knowledge to fully leverage the upcoming release. Make sure to bookmark Be Release Ready and visit often to discover the latest resources for Salesforce Admins.