Why Is Everyone Talking About Salesforce Flow Approvals?

In the Spring ’25 release, Salesforce introduced Flow Approvals to replace the legacy approval processes. This approval platform was based on the orchestration functionality. I recorded and released two videos and posts to share this functionality on Salesforce Break. The videos saw great interest from the community, they are about to reach 20K views soon. So, why is everyone talking about flow approvals?

There are multiple reasons:

1. Flow approvals are orchestration-based, but they are entirely free unlike other orchestrations.
2. Legacy approvals are really old. Salesforce has not been investing in them. They are past due for a remake.
3. Legacy approvals are limited. To enhance the functionality, clients had to use AppExchange solutions or paid alternatives by Salesforce like advanced approvals for CPQ.
4. Flow approvals allow for parallel approvals, dynamic steps, and flexibility in the approval process.

This is why I decided to create more content in this area, starting with:

1. A live course that teaches Flow Approval processes in depth, with hands-on practice. See the details here, and reach out if you’re interested.
2. Additional resources focused on solutions that bridge the gaps between Flow Approvals and Legacy Approvals, addressing the limitations of the new platform.

Here is the first post detailing a solution filling one of the gaps.

Flow Approvals Don’t Provide Sufficient Detail In The Related Lists

Here is the first point I would like to address: Flow approvals don’t provide good detailed information in the related lists of the object record like the legacy approvals did.

Solution: Build a screen flow with reactive data tables to show the approval submission records and their related records. Add the screen flow to a tab on the record page.

Salesforce provided a component that can be added to the record page. It is called the Approval Trace component. This provides some information about the approval process, but is not customizable. I asked myself how I can go beyond that, and decided to build a reactive screen flow with data tables to fill this functionality gap. Here is what the output looks like:

To build and deploy this flow, you need to follow these steps:

1. Build the screen flow.
2. Build the autolaunched flow that will fetch the data you will need. This flow will be used as the screen action in step one.
3. After testing and activation, add the screen flow to the record page.

If you have never built a screen flow with screen actions before, let me be the first one to tell you that step one and two are not really completed in sequence. You go back and forth building these two flows.

Let’s get started.

Build the Flow Approval Submission Screen Flow

What I usually do, when building these flows is that I first get the screen flow started. Then I build the autolaunched flow, and go back to the screen flow to build out the rest of the functionality. The reason is that the screen flow data tables will need the outputs from the autolaunched flow to be fully configured.

This is what the screen flow looks like, once it is completed.

For now, you can just ignore the loop section. This is there to ensure that there is a default selection for the first data table, when the flow first runs.

This is the structure of the flow excluding that part:

1. Get all approval submission records for the recordId that will be provided as input into the flow.
2. Check if there are approval submissions found.
3. Display a screen saying “no records were found,” if the get returns null.
4. Display a reactive screen mainly consisting of three data tables with conditional visibility calling an autolaunched flow as a screen action.

Here is what this screen looks like:

After you build, test, and activate the autolaunched flow, configure the screen action under the screen properties as shown below.

How the Loop Section Works

The first data table has an input parameter that determines the default selection, when the flow first runs. This is a record variable representing one of the members of the collection record variable that supplies the data. You need to loop the collection of records to get to the record variable. Follow these steps:

1. Loop the collection record variable which is the output of your get step. Sort the data by last modified date in your get step.
2. Assign the first member to a record variable.
3. Exit the loop without condition. Connect the path to the next element outside the loop.
4. Add the resulting record variable to the default selection parameter under the configure rows section of your data table.

This loop always runs once, setting the default selection to the most recent approval submission. This populates the related data tables when the flow first runs.

Build the Screen Action Autolaunched Flow for Related Lists

The autolaunched flow receives a single approval submission recordId as input. Then it gets the related records and data the screen flow needs, and returns the data as output.

Here is a screenshot of the autolaunched flow.

This flow executes the following steps:

1. Gets the approval submission data.
2. Gets the user data for the submitter to resolve the full name.
3. Gets approval work items.
4. Checks null and sets a boolean (checkbox) variable when the get returns null. The output uses this variable to control conditional visibility of the relevant data table. If found this method yields the best results.
5. Get approval submission details.
6. Checks null and sets a boolean variable when the get returns null. This variable is then used in the output to drive conditional visibility of the relevant data table.
7. Assigns the get results to output collection record variables.

Final Deployment Steps

After testing and activating the autolaunched flow, you need to add the flow to the screen flow as the screen action. The flow input will be fed from the selection of the first data table. You will see that this step will make all the outputs of the autolaunched flow available for the screen flow. Using these outputs build the additional two data tables and configure the conditional visibility.

After testing and activating your screen flow, add the flow to the record page on a dedicated new tab (or to a section on an existing tab). Select the checkbox to pass the recordId to the flow. Note that this flow will work with any record for any object.

Limitations and Suggested Improvements

While this screen flow provides a lot of detail and customization options it has two limitations:

1. By default, the data table does not resolve and display record names in lookup fields when you add these fields as columns. To address this, I added the submitter’s full name in a read-only text field for display on the screen. Workaround: Create formula fields on the object and display those in the data table.
2. The data tables do not provide a clickable link. Combined with the limitation above, you can create a formula field on the object to address both of these gaps: show the record name and make it a clickable link. Here is the formula example you need for this (shout out goes to Brad Weller for his contribution): HYPERLINK("/" & Id, Name, '_self')

While I wanted to make these additions to these flows, I did not want to add custom fields to the objects. It should be your decision whether you want to do that or not.

Install the Package to Your Dev Org

Here is the second generation unprotected package for these two flows that you can install in your Dev Org:

Install the Unprotected 2GP

For a more visual walk through of how these flows are built, watch the Salesforce Break YouTube video below.

With Salesforce phasing out legacy approvals, mastering Flow Approvals is essential to keep your org’s processes modern, flexible, and future-ready. Gain the confidence to handle any approval challenge with solutions that work seamlessly in real-world Salesforce environments HERE.

Explore related content:

Supercharge Your Approvals with Salesforce Flow Approval Processes

When Your DMLs Have Criteria Conditions Other Than Id

Start Autolaunched Flow Approvals From A Button

Get Ready for the New Time Data Type – Summer ‘25 Flow Goodness

#AutolaunchedFlow #FlowApprovals #FlowBuilder #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials

Get Ready for the New Time Data Type – Summer ‘25 Flow Goodness

Salesforce Flow is constantly evolving, bringing us enhancements that make our lives as admins, developers, and business users much easier. The Summer ‘25 release is described as a big one, packed with substantial updates and quality-of-life improvements. Among these exciting additions is a feature many have been waiting for: native support for the Time data type in Flow.

What is the Time Data Type and Why is it Important?

The new Time data type is specifically designed for situations where the time of day matters, but the date does not. Previously, handling time-specific data in Flow without including the date could be complex. Summer ’25 changes that, allowing you to process data focused purely on time, down to the millisecond.

This capability is incredibly handy for a variety of use cases:

• Managing communication times, such as determining when to send an email.
• Checking if actions occur within specific business hours.
• Creating flows to send reminders based on a time before an event, like an email reminder 30 minutes before a meeting.

Where Can You Use the Time Data Type in Flow?

The Time data type is available across a wide range of Flow features, providing flexibility in how you build your automations. You can use Time fields and resources in:

• Various Flow elements, including Action, Assignment, Collection Filter, Collection Sort, Create Records, Delete Records, Decision, Get Records, Subflow, Transform, Update Records, and Wait for Conditions.
• Formula builder and expression builder.
• Resources such as variables and constants.
• As input and output for invocable actions.

When working with time values, you should use the hh:mm:ss.SSS AM/PM format, though including seconds or milliseconds is optional. For instance, 9:00 AM, 5:30:05 PM, and 14:45:53.650 PM are all valid time values.

New and Improved Time Functions

To complement the new data type, Salesforce Flow also introduces or enhances formula functions specifically for working with time. In the formula editor, you can now effectively use functions such as HOUR(), MINUTE(), SECOND(), MILLISECOND(), TIMENOW(), and TIMEVALUE(). These functions empower you to perform calculations and make decisions based on time data within your flows. Previously, extracting and manipulating time in Date/Time fields was very difficult, and it involved parsing text values that contained this information.

Important Considerations

• The Time data type is currently not supported in the offline flows available on the Salesforce Mobile app.
• This change applies to flows running on API version 64.0 or later. If you have existing flows created with API version 63.0 or earlier that use custom fields of the time data type, they will continue to work as before. However, to leverage the full functionality of the updated time data type in those flows, you’ll need to edit them and save them as a new version configured to run on API version 64.0.

Random Number Generation

One benefit of the new time-related capabilities is that you can use the new functions to generate random numbers. There is no random number generator function available in flow. Previously, I extracted the seconds out of a Date/Time value to generate a random number, now I can generate one using the Milliseconds.

Select multiple leads on a data table to add them to a prize drawing. Generate a random number and determine the winner. Email the winner to communicate the prize they won.

For this use case I leveraged many new flow functionalities.

Let’s get right to the build.

Build the Screen Action Autolaunched Flow

The selected leads can span over several screens in the data table, when the user is completing their selection. I decided to use an autolaunched flow to compile a CSV list of lead names which will be shown under the data table, as the user is completing their selection.

For that I build an autolaunched flow. Follow these instructions to build yours:

1. Start an autolaunched flow.
2. Create a Lead Collection Record Variable and make it available for input.
3. Create a Name CSV Text Variable and make it available for output.
4. Use the transform element to extract a text collection variable of names (first names) out of the lead collection record variable (not required, I wanted to use this new feature).
5. Loop the names collection text variable.
6. Add an assignment to add the current name text, and then a comma and a space character to the Name CSV Text Variable.
7. Outside the loop add another assignment to assign a new value to the Name CSV Text Variable. This new value will be the accumulated names in csv format with the last comma and the space character removed. Use a formula resource to compute the value. The formula is: LEFT({!NameCSVTextVar},LEN({!NameCSVTextVar})-2)
8. Debug, save and activate the flow.

Build the Screen Flow

Follow these instruction to build your flow:

1. 1. Start a screen flow.
   2. Get the leads in the org where the email is no null (limit the get to 2,000 records not to hit limits).
   3. Add a screen. Place a data table on the screen showing the leads, and allow for multi selection. Add a screen action to the screen and point it to the autolaunched flow you created above. Pass the Lead Data Table Selected Rows to the screen action autolaunched flow as input.
   4. Assign the count to a Count Number Variable (no decimals). Also assign the winner number to a Winner Count Variable. This is to ensure that the number does not change in debug (I don’t think it will change in production execution). You will need a formula resource to determine the winner. Here is what this formula does: Generate a number between 1 and 1,000 using the milliseconds value of the time of the execution, and prorate that using the number of leads the user selected to determine the winning number. Assign the following formula value to the Winner Count Variable:ROUND(((MILLISECOND(TIMENOW())+1)*{!CountLeadsVar}/1000),0)+1
   5. Loop the Lead Data Table Selected Rows and assign a value incremented by 1 to a counter variable in every iteration (CounterVar Add 1).
   6. Check Via a decision whether the winning number is equal to the counter variable.
   7. If the winner is determined assign the Lead Record to the Winning Lead Record Variable, and exit loop. If not, keep looping.
   8. Outside the loop send the email to the email address of the winning lead and congratulate them. I built my email template with inside the brand new email action element for this one (Summer ’25).
   9. Debug, save and activate the flow.

Please note that, I tried conditionally running the screen action only after the user selects the first data table row, but that functionality (Summer ’25) does not seem to work properly in preview. I have a ticket open with Salesforce to determine whether that is a bug.

If you want to see the flow in action, watch this video.

Conclusion

The introduction of the Time data type is a significant step forward for Flow, enabling more precise and efficient time-based automation. It’s one of the many high-impact features and quality-of-life improvements packed into the Summer ’25 release that are bound to make your job easier.

Ready to give it a spin? Don’t forget to sign up for a pre-release org to test out this and other new features! You can also find more details in the Summer ’25 release notes.

Explore related content:

Salesforce Summer ’25 Preview: Major Flow Changes to Watch For

Time Zone and Time Operations in Flow

Supercharge Your Approvals with Salesforce Flow Approval Processes

#AutolaunchedFlow #DecisionElement #GetRecords #Salesforce #SalesforceAdmins #SalesforceDevelopers #SalesforceTutorials #Summer25 #Time #TimeDataType