New Flow Approval Process Action in Salesforce Summer '25

The new Flow Approval Process update in Summer '25

Summer '25 lets you call a Flow Approval Process directly from another flow, and it's about time. I've seen so many teams struggle with messy workarounds just to trigger an approval without writing code. Now all that logic can sit inside Flow Builder where it belongs.

Before this, starting an approval from a flow usually meant reaching for Apex or some tricky platform events. It worked, but it wasn't exactly clean. Now we have a dedicated Action element for it, which is much simpler to manage, especially if you're trying to decide between Apex vs Flow for your automation strategy.

Flow Builder showing a workflow diagram with the Action element highlighted.

Setting up your first Flow Approval Process action

The setup is pretty straightforward. You'll need an autolaunched flow to act as the "caller" and an active autolaunched Flow Approval Process to be the "target". When you add the Action element in your flow, you search for the name of your approval process and pass in the record ID.

I've worked on projects where we had complex order approvals that changed based on the region or the discount percentage. In the past, that meant a lot of branching logic or multiple Apex triggers. With this update, you can build a single orchestrator flow that looks at the record data and then picks exactly which Flow Approval Process to fire off.

How to get it running

• First, make sure your autolaunched Flow Approval Process is active. You can't call it if it's still in draft mode.
• Open your main flow and drop in an Action element.
• Search for your approval process by name.
• Map your variables. You'll usually just need the recordId, but you can pass in comments or other custom inputs too.
• Don't forget to add a fault path. If the approval fails to start because of entry criteria, your flow will crash without one.

One thing that trips people up: the approval process must be the "autolaunched" type. If you try to call a standard legacy approval process this way, it won't show up in the list. Stick to the new Flow-based approvals to make this work.

Why the Flow Approval Process update matters for admins

So why does this matter? The short answer is maintenance. When you use code to trigger approvals, you're creating a black box that other admins might not understand. With a Flow Approval Process, everything is visual. If the business logic changes, you just update the flow. No deployment packages or unit tests required for a simple logic tweak.

It also gets you most of the way to mastering the Apex approval process concepts without actually writing the code. Same power, a lot less overhead. I've seen teams save hours of dev time just by moving these types of triggers into Flow.

Real-world use cases

• Use a decision element to check a field and then call a specific Flow Approval Process for high-value accounts.
• Build a Screen Flow that gathers some notes from a user and then kicks off the approval process in the background.
• Show a user-friendly message when an approval fails to start, instead of that generic "unhandled fault" red text.

Key takeaways

• Summer '25 lets you call an autolaunched Flow Approval Process directly from the Flow Action element.
• It removes the need for Apex workarounds or platform events to trigger approvals.
• You can pass custom variables like comments or record IDs directly into the approval.
• Always use fault paths to handle cases where entry criteria aren't met.

This is a real step toward Flow being the one place your business logic lives. If you've been putting off moving your approvals into Flow, now is the time to start. It's cleaner, faster to build, and way easier to fix when things go wrong. Give it a shot in your next sandbox refresh and see how much code you can delete.