Unanimous Flow Approvals – No More Workarounds
Summer 26 Release Flow Approval Improvements
The Summer ’26 release is packing some serious Flow upgrades that move us closer to smoother automation. For the Flownatic community, this release represents a strategic shift: Salesforce is removing the roadblocks that have slowed us down, closing permission gaps, and allowing us to handle enterprise-grade complexity without the need for custom-coded workarounds.
In this post, we’re diving into two of the biggest wins for Flow Approvals this cycle: native unanimous consent for group approvals and expanded dependency visibility. Both are overdue fixes that change how we build compliance-ready automation.
Unanimous Consent
If you have ever had to build a compliance-heavy workflow that requires sign-off from an entire committee, you know the previous “administrative nightmare.” To ensure ten people all granted approval, admins were often forced to create ten separate, sequential approval steps: a maintenance disaster that was as fragile as it was tedious.
Summer ’26 introduces native unanimous consent for group approvals, turning what used to be a complex workaround into a single, elegant configuration. Here is the explanation of how these native mechanics operate:
- Individual Work Items: When a step is assigned to a group needing unanimous consent, every single member of that group receives their own unique work item in their queue.
- Approval Logic: The process is strictly gated by total agreement. The approval step only advances to the next stage if every member of the group grants their approval.
- Rejection Behavior: Accountability is immediate and efficient. A single rejection by any group member closes the step instantly. Most importantly, the system automatically withdraws all other pending work items for that group, effectively cleaning up user queues and preventing “zombie” work items from lingering.
- Security Guardrail: To maintain the integrity of the specific stakeholder group and ensure compliance, work items in these unanimous approval steps cannot be reassigned.
This is a massive architectural lever for those responsible for high-stakes data integrity, allowing us to build multi-stakeholder reviews without the bloat of previous releases.
Dependency Visibility
Historically, “god-mode” permissions have gated visibility into how your automation interacts with approval processes. Therefore, business analysts and process designers were flying blind. Summer ’26 lets teams see process logic without handing over admin access.
Previous Requirement: Previously, access to view flow dependencies within the Approvals app was restricted to users with the Manage Flow permission. This forced admins to give high-level, backend access to users who simply needed to understand process connections, creating a significant security risk.
New Requirement: Users with the Approval Designer permission can now view dependencies directly within the Approvals app.
This is a huge win for admins concerned with security. We can now empower our team members to understand the underlying logic and connections of their approval processes without handed out the keys to the entire Flow Builder backend.
Compatibility and Availability
Salesforce built these updates for the modern Lightning experience, and they’re available across all flagship editions.
Platform: These updates apply specifically to Lightning Experience.
Salesforce Editions:
- Enterprise
- Performance
- Unlimited
- Einstein 1
- Developer
Closing the Gap on Compliance
The updates to Flow Approvals in Summer ’26 are significant architectural improvements. Salesforce is eliminating the need for complex, manual workarounds that have historically crowded our orgs. These changes move us closer to a “no-code/low-code” enterprise reality where automation is both compliant and powerful. For admins who have spent years patching approval logic together, this release is a genuine exhale. And for organizations managing strict regulatory requirements, tighter permission scoping is a real compliance architecture upgrade.
As we march toward the Agentic Enterprise, these controls ensure that our frameworks remain scalable and secure. Now it’s time to put them to work. Head into your sandbox, pull up Flow Builder, and see how much simpler your next approval process can be. Happy building, Flownatics!
Explore related content:
Visual Comparison and Beyond – Flow Versions Just Got Easier
Supercharge Your Approvals with Salesforce Flow Approval Processes
I’m configuring a flow approval using the new ‘Require unanimous approval’ setting. However, when testing (in sandbox), not all of the users in my public group are getting an Approval Work Item assigned. I’ve ruled out the following:
Users have CRED access to Approval Work Items
Not an issue with an invalid email address (some users have .invalid email address. Some got an AWI…some did not).
All users are active
Not sure what else I should be checking but it’s odd that not all of my users are getting the AWI assignment. Any thoughts?
I will check it out, will answer.
Here is what I see: When I assign an approval step to a public group, a work item for the group is created. If the unanimous approval checkbox is on, the system creates a separate work item for each member. See the screenshot. Never mind the first work item, that is the next step that was launched parallel. See the next three lines. The Sales Team has two members and there is a work item for each. Check image: https://salesforcebreak.com/wp-content/uploads/2026/10/UnanimousApprovalExample.png
Yes, I expected the same. There should be an AWI for the group and a separate AWI assigned to each member of the public group. However it’s not assigning it to all members of my public group. I’m not sure why.
Are all users top level members? Do you have users within users? Are all users flow enabled? What are their licenses?
Sorry, I mistyped. Correction: Do you have groups within groups? A user can be a direct member of the public group, or a group that user is a member of can be a member of the group you are using in your approval process. I have not tested whether this works well or not.
Nothing fancy as that. Just users assigned directly to the group. No groups within groups. I opened a SF case since I can’t seem to figure out why.
I figured it out. It was a oversight mistake on my part. I didn’t realize the affected users were frozen in my sandbox org.
Thanks for letting us know. It happens.