Salesforce Summer ‘25 Release: Enhance Your Screen Flows With Screen Actions

Lately, every Salesforce release has been packed with amazing new features, especially when it comes to Flow Builder. With Salesforce professionals turning more and more to Flow as the one-stop shop for declarative automations, it comes as no surprise that the tool keeps evolving to support more requirements faster while offering a seamless experience for both end users and Salesforce professionals.

In this post, we’ll cover how the new Screen Actions, which will be generally available in Summer ‘25, can take your Screen Flow reactivity game to new heights! 

Salesforce Screen Flows

Ever since they were introduced, Screen Flows have been an innovation for no-code processes in Salesforce, as no other declarative tool at the time could allow Salesforce professionals to create a seamless step-by-step visual experience for their internal or external users.

Screen Flows can guide users through virtually any business process by providing instructions or call scripts, gathering user input, and then performing behind-the-scenes actions such as Record Create or Record Update. With each release, Flow Builder becomes increasingly robust, and Screen Flow-specific functionality is no exception.

Before we proceed, you should be familiar with creating Screen Flows and Autolaunched Flows. If you haven’t created your first Screen Flow yet, we’ve got you covered – pause here, check out the guide below, then come back to further enhance the example, as we’ll expand on the same one from the guide, which allows users to create a new contact from the Homepage.

Flow Action Buttons

Back in the Summer ‘24, Salesforce introduced an exciting new way to transform your Screen Flows: the Action Button. Just as the name suggests, this is a button users can click to trigger an action – what that action will be is totally up to you!

Before creating a new contact through the Screen Flow, if we want our users to see existing contacts from the selected account, start an automation and receive a confirmation message, or even require them to trigger a duplicate check, Action Buttons allow us to add all these features and more!

To display the contacts from the account the user selects in a table following the click of the button on the same screen, we can now simply drag an Action Button component and employ an Autolaunched Flow to return the records. Before this was an option, at least two screens would have been needed, with a Get Records element in between.

The Account Id from the lookup will be used as an input value for the Autolaunched Flow, which will retrieve the associated contacts. The records are stored in a collection variable, which has to be made available for output in order to become usable in the Screen Flow – in this instance, as a source for the Data Table.

To enhance the experience even more, you could create a formula to control when the button will be disabled, as well as further tweak when the button or table is displayed. In the end, this is just a simple example, but in a real-life scenario, all these will differ based on the use case at hand. If you haven’t used Action Buttons just yet, make sure to check out the deep dive article below!

While Action Buttons are amazing and can be just what your team was looking for in multiple scenarios, what if your users didn’t have to click a button at all, allowing them to continue through the wizard at lightning speed?

Go Further with Screen Actions

Screen Actions are a more recent addition to the Screen Flow capabilities, having been introduced in Spring ‘25. Now, just one release later, they are already seeing significant improvements that give you, as the Flow creator, even more control over their behavior.

These are very similar to how Action Buttons work, minus the button click. While Screen Actions still use an underlying Autolaunched Flow to either retrieve information or perform the actions you choose, the need for the user to do an extra step is removed – meaning the Screen Flow can progress faster with fewer screens, less input from the user, and more screen reactivity than ever before!

Adding a Screen Action or, if it makes sense, migrating from an Action Button to an automatically triggered Screen Action, will not entail a separate component on the screen, as these can be directly configured within the Screen Properties. Going back to our example, the same Autolaunched Flow will be used, but this time there will be no button, as everything will happen in the background using the user’s input.

When configuring the Screen Action, pay close attention to the Action Run Settings. The Account Id from the lookup will still be the input variable, but for Screen Actions, there are a few more options to set – not only when the action will run on screen load, but also any run conditions you may want to use to determine when the action will be executed. The output collection variable, varAllContacts, will once again be used as the source collection for the Data Table.

For both Action Buttons and Screen Actions, once the action itself is configured, you can tap into additional resources in your process to either filter component visibility or determine the following steps. These include whether the action was successful, any error messages, and the actual outputs from the Autolaunched Flow.

Since in our example the only custom output variable is a record collection, it is not available for selection in Component Visibility. However, a text variable or a single record would be. In the end, having access to these resources adds yet another layer of flexibility in terms of what can be achieved.

Once the changes are ready and the Flow has been tested in debug mode to ensure everything works as expected, let’s see it in action directly on the homepage!

With the first Screen Action working as intended, let’s add another one! I mentioned the duplicate check possibility above; however, this use case would be better for an automatically triggered Screen Action than for an Action Button, wouldn’t it?

By leveraging a combination of Autolaunched Flow, Screen Action, and the Validate Input option for the Email field, a custom duplicate check process can be created. This can be further enhanced as needs shift over time or as more complex matching rules are required. While multiple steps happen in the background, the user ultimately sees everything on a single screen based on the input they provide.

Considerations

• Multiple Screen Actions can be chosen for each Screen element, unrelated to each other. 
• The Autolaunched Flow has to exist and be active to become an option for the Screen Action.  
• By default – and as recommended – the Screen Action is triggered whenever the field is changed or the Flow is triggered, except when a user navigates to a screen by clicking the Previous button on the next screen.
• The other available option is to run only the first time the screen loads, but as of Summer ‘25, you can also set run conditions depending on the desired behavior. 
• The amount of data returned by the Autolaunched Flow and displayed in the Screen Flow can increase loading time, so in scenarios such as the Get Records one above, it may be a good idea to either limit the number of records or include additional filters. 
• Also, make sure to check the data safety considerations for both Screen Flows and Autolaunched Flows here.

Final Thoughts

Having both Action Buttons and Screen Actions available to enhance new or existing Screen Flows is a gamechanger when it comes to both user experience and meeting complex business requirements with readily available components.

With Screen Actions allowing users to focus only on the input they must provide, while the rest of the magic happens in the background, make sure to review any existing Screen Flows with multiple screens you might have – some complexity could be removed by leveraging this feature instead.

Have you already used Screen Actions in your org? Let us know your thoughts in the comments below!