Salesforce Spring ’26 Brings Major Debug Improvements to Flow Builder

If you’ve been building flows for any length of time, you already know this: a lot of the real work and time goes into debugging. It’s re-running the same automation over and over. Swapping out record IDs. Resetting input values. Clicking Debug, making a small change, saving, and sometimes starting the whole setup again. That loop is where Flow builders spend a lot of their time, especially once flows get even moderately complex.

Salesforce’s Spring ’26 release finally takes aim at that reality. Instead of piling on new features, this update focuses on removing friction from the debugging experience itself. The result is a Flow Builder that feels faster, less disruptive, and much closer to a modern development environment.

Debug Sessions That Don’t Forget Everything

One of the most impactful improvements in Spring ’26 is also one of the simplest: Flow Builder now remembers your debug configuration while you’re actively editing a flow. When you debug a flow, make a change, and save, Salesforce preserves the triggering record you used, your debug options, and your input variable values. That means no more losing your setup every time you click Save, no more re-pasting record IDs, and no more rebuilding your test scenario from scratch.

Your debug session stays intact until you refresh your browser, close Flow Builder, or manually click Reset Debug Settings. This is a big quality-of-life upgrade, especially if you work with record-triggered flows that have edge cases, complex decision logic, multi-screen flows with test data, or anything that requires several small iterations to get right. The practical impact is simple: you can now fix, save, and re-run flows much faster, without constantly breaking your momentum.

Flow Tests Are No Longer “Latest Version Only”

Spring ’26 also changes how flow tests work behind the scenes.

Previously, flow tests were tied only to the latest version of a flow. As soon as you created a new version, older tests were essentially left behind. If a test no longer applied, you deleted it. If it still applied, you recreated it. Now, tests can be associated with specific flow versions.

You can now reuse the same test across multiple flow versions or limit it to only the versions it truly belongs to, and when you create a new version, Salesforce automatically carries those tests forward from the version you cloned. This gives you much tighter control over scenarios like preserving regression tests for older logic, maintaining multiple supported versions, validating breaking changes, and keeping historical test coverage intact. Instead of treating tests as disposable, they become part of your flow’s lifecycle. This is a foundational shift for teams building mission-critical automation.

Compare Screen Flow Versions to See What Changed

Salesforce has had version comparison in other areas of the platform, but Spring ’26 brings it to screen flows. You can now compare any two versions of a screen flow and instantly see what changed across elements, resources, fields, components, properties, and styles.

This makes it much easier to answer the first question most debugging starts with: what changed? Instead of manually opening versions side by side, you get a clear view of differences, helping you pinpoint where issues may have been introduced and focus your testing where it actually matters.

More Control When Debugging Approvals and Orchestrations

Debugging long approval chains or orchestrations has always been painful. You’d often have to run the entire thing just to test one step. Spring ’26 introduces several upgrades that make this far more surgical.

Complete work items directly in Flow Builder

You can now complete orchestration and approval work items without leaving Flow Builder.

While debugging, interactive steps can be opened directly on the canvas. Once completed, the orchestration or approval process resumes immediately.

This keeps the entire test cycle inside the builder instead of bouncing between apps, emails, and work queues.

Debug only the part you care about

You can now define a start point, an end point, or both when debugging orchestration and approval flows, which gives you much more control over what actually runs. Instead of being forced to execute the entire automation, you can skip earlier stages, stop before downstream logic, isolate a single phase, or focus on one problematic section. When you skip steps, you can also provide test inputs to simulate outputs from earlier stages. In other words, you no longer have to run the whole machine just to test one gear.

Selectively control which steps execute

Salesforce has expanded test output controls beyond rollback mode.

You can now decide which orchestration or approval steps should run while debugging, and which should be skipped, directly from the new Configure Test Output experience.

This makes it much easier to validate edge cases, exception handling, and conditional behavior without unnecessary noise.

Smarter Debugging for More Advanced Flow Types

Spring ’26 also delivers improvements for more specialized use cases.

Segment-Triggered Flows: Testing multiple records at once

For segment-triggered flows, you can now debug up to ten records at the same time instead of testing one record after another. You can select multiple segment members, run the debugger, and cycle through each result to see exactly how different records move through your flow.

The canvas highlights the active path for the selected record, and you can filter results by successes or failures, making it much easier to spot inconsistencies. This is especially useful when validating logic across different customer types, messy or incomplete data, and edge cases that would normally take many separate test runs to uncover.

Why This Release Actually Matters

It’s easy to skim release notes and see “debug improvements” as minor polish, but debugging speed directly affects how confidently people build automation, how complex flows can realistically become, how quickly teams can ship fixes, and how much risk is involved in every change.

With these changes, you can rerun the same scenarios without constantly rebuilding your debug setup, test individual flow versions with far more precision, and isolate only the parts of your logic you actually care about. You can walk through approvals and orchestrations directly inside Flow Builder instead of jumping between tools, and even validate how a flow behaves across multiple records in a single debug run. This is the kind of release that changes how Flow Builder feels to use.

Conclusion

Salesforce has spent the last few releases expanding what Flow can do, and Spring ’26 is about improving how Flow is built. Persistent debug sessions, version-aware tests, selective execution, in-builder work items, and targeted debugging all point in the same direction. Flow Builder is evolving from a configuration tool into a true development environment.

If you build anything non-trivial in Flow, these changes will save you time immediately. And if you teach, support, or scale Flow across teams, they open the door to far better testing practices going forward.

Explore related content:

Top Spring ’26 Salesforce Flow Features

Add Salesforce Files and Attachments to Multiple Related Lists On Content Document Trigger

Spring ’26 Release Notes: Highlights for Admins and Developers

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

【Saleforce】フロービルダーのBeforeトリガーと割り当て
https://qiita.com/Tatsuhiro_Iwasaki/items/f20c5ffb5578b98eadfc?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

#qiita #Salesforce #FlowBuilder