Seven Summer '26 Flow Updates That Add Up

This is the kind of Summer '26 bundle that is easy to miss because none of the individual notes is enormous.

But together, they make Flow feel more mature.

The theme is not "Flow got one giant feature".

The theme is:

fewer formula workarounds
better screen-flow usability
safer approvals
more predictable scheduled automation
less awkward Apex action configuration
more control over how Flow screens look

That matters because most Flow pain is not dramatic. It is small friction repeated across dozens of automations.

Quick snapshot

Unanimous group approvals: approval steps assigned to groups can require every group member to approve.
Scheduled-flow batching: scheduled flows can use a custom batch size from 1 to 200.
Date operators: Decision elements get date-specific operators such as Is Today, Is Anniversary of Today, and Last Number of Days.
Data Table lookup columns: screen-flow Data Tables in Aura and LWR sites can show related record names instead of IDs, with links to open those records.
More styling overrides: more standard screen components support Style tab overrides.
Apex-defined inputs: admins can set fields directly for Apex-defined action inputs.
Custom screen component styling: custom Flow screen components can expose style settings to Flow Builder.

My short version:

Flow is becoming less workaround-shaped.

1. Unanimous approval for groups

This is a big deal for approval processes that were always pretending a group was a single approver.

With unanimous approval, a step assigned to a group can require every group member to approve before the step moves forward.

That is useful for:

compliance review
legal approval
finance sign-off
change advisory boards
security exceptions
partner governance

The old workaround was usually clumsy:

Step 1: Legal approver A
Step 2: Legal approver B
Step 3: Legal approver C

or:

Assign to group and hope the first response is enough.

Neither is quite right.

Unanimous group approval models the business rule directly:

All members of this group must approve.

The important caveat is operational. Salesforce's approval email documentation says approval work items from unanimous approval steps cannot be reassigned. So this works best when group membership is clean before the approval starts.

Practical rule:

Use unanimous approval for real consensus requirements, not because it sounds more thorough.

If one group member is on leave, wrong, or stale, the process can stall.

2. Scheduled-flow batching

Scheduled flows can now use a custom batch size from 1 to 200, configured from the Start element.

Previously, scheduled flows processed interviews in the default batch size of 200.

That default is fine for simple work.

It is not always fine for heavy flows.

For example, imagine a nightly scheduled flow that:

finds renewal records
updates related tasks
sends notifications
calls an Apex action
creates audit records

At 200 records per batch, that may hit limits or stress downstream logic.

With a smaller batch size, you can trade total run time for safer execution.

Simple update flow: batch size 200
Moderate flow with related DML: batch size 50
Heavy flow with Apex actions: batch size 10 or 25
Flow with callouts or fragile downstream limits: test very carefully

This is not a magic performance button.

It is a pressure valve.

Smaller batches can reduce per-transaction pressure, but they can also increase total execution time. The right value is something you measure, not something you guess once and forget.

3. Date operators in Decision logic

This one will remove a lot of little formula resources.

Decision elements can now use date operators when the condition uses a Date data type. Salesforce calls out operators such as:

Is Today
Is Anniversary of Today
Last Number of Days

That makes simple date-driven branching readable.

Before:

Formula resource:
TODAY() = {!Renewal_Date__c}

Decision:
{!IsRenewalToday} Equals True

After:

Decision:
Renewal Date Is Today

That is better for the next admin who opens the flow.

Good candidates:

renewal reminders
birthday or anniversary paths
"created in the last X days" logic
upcoming expiry windows
stale case follow-up
contract review reminders

The value is not just fewer resources.

It is that the business rule is visible where the branch happens.

4. Data Table lookup columns get human-readable

This is small, but it is the sort of small that makes screen flows feel less unfinished.

In screen flows added to Aura and LWR sites, Data Table lookup columns can show related record names instead of Salesforce IDs. Salesforce also says you can turn the record name into a link that opens the related record in a new browser tab.

That changes the experience from this:

Account
0018a00002abcXYZ

to this:

Account
Edge Communications

and ideally:

Edge Communications -> opens the account

This matters for partner portals, service flows, and guided support experiences.

Users should not have to decode record IDs in a UI that is supposed to help them make a decision.

5. More screen components support styling overrides

Summer '26 also expands styling overrides for more screen-flow components.

Salesforce lists these newly supported components:

Action Button
Address
Choice Lookup
Dependent Picklists
Email
Lookup
Name
Phone
Slider
Toggle
URL

That is useful, especially for Experience Cloud and guided screen flows where the default component styling can feel slightly disconnected from the surrounding site.

But I would use this carefully.

Good styling overrides:

align spacing with a portal page
make a primary action easier to spot
improve scanability in a dense screen
match a support or onboarding flow to the site theme
keep repeated screens visually consistent

Bad styling overrides:

one-off colours in every screen
tiny text to fit too much on the page
custom styling that breaks accessibility
different visual treatment for the same component in different flows
making Flow screens look like a separate product by accident

The goal is consistency, not decoration.

6. Apex-defined inputs become easier to configure

This connects directly to Flow-friendly Apex design.

Set Field Values Directly for Apex-Defined Inputs means admins can configure fields inside an Apex-defined input directly in the action property panel.

That removes a common bit of Flow ceremony.

Before, the builder often had to:

Create an Apex-defined variable.
Add an Assignment element.
Set fields on that variable.
Pass the variable into the Apex action.

Now the action configuration can be more direct.

That is cleaner, but it also makes input design more important.

If your Apex-defined type exposes confusing fields, Flow Builder will faithfully show confusing fields.

So design the DTO like an admin-facing configuration surface.

public class NotificationRequest {
    public NotificationRequest() {}

    @InvocableVariable(
        label='Recipient User ID'
        description='The Salesforce user who receives the notification.'
        required=true
    )
    public Id recipientUserId;

    @InvocableVariable(
        label='Message'
        description='Plain text message shown to the recipient.'
        required=true
    )
    public String message;

    @InvocableVariable(
        label='Related Record ID'
        description='Optional record opened when the user clicks the notification.'
    )
    public Id relatedRecordId;
}

The nicer Flow Builder UI does not rescue a vague Apex contract.

It makes the contract more visible.

7. Custom Flow screen components can expose style settings

This is the developer-side complement to styling overrides.

If you build custom Flow screen components, exposing style settings gives Flow builders a more standard way to configure presentation without asking you to add random one-off properties for every project.

The design discipline is the same as with state managers and raw UI components:

expose useful styling controls
keep defaults good
use labels admins understand
avoid turning the property panel into CSS-in-Flow
preserve accessibility
support design-system consistency

For example, this is a good kind of setting:

Density: Comfortable | Compact
Emphasis: Default | Highlight | Warning

This is usually not:

marginTopPx
headingHexColour
buttonBorderRadiusOverride

You want enough styling control for admins to fit the component into a screen flow.

You do not want every flow to become its own design system.

The bigger pattern

These updates are small, but they all move Flow in the same direction.


Unanimous group approvals	Manual multi-step approval workarounds
Scheduled-flow batching	All-or-nothing default batch pressure
Date operators	Formula resources for basic date branching
Data Table lookup names	Record IDs in user-facing tables
More styling overrides	Custom components for simple visual alignment
Direct Apex-defined inputs	Assignment elements just to build input objects
Custom component style settings	Hard-coded or bespoke presentation props

That is why this is worth writing about.

Flow does not only get better when it gets bigger features.

It gets better when the obvious path becomes the clean path.

Practical rollout

I would look for these opportunities first:

approval steps assigned to groups where everyone really must approve
scheduled flows that sometimes hit limits or time out
Decision elements with formula resources named like IsToday, IsInLast30Days, or IsAnniversary
screen-flow Data Tables showing lookup IDs to users
Experience Cloud flows with awkward default styling
Apex actions that require building input wrapper variables manually
custom screen components with too many ad hoc style properties

Those are the places where Summer '26 removes friction immediately.

Final take

This is a very Flow-builder release note cluster.

Not flashy.

Very useful.

The best part is that these changes improve the daily experience of admins and developers who already build Flow seriously. Fewer workarounds, clearer screens, better approval semantics, safer scheduled automation, and cleaner Apex action configuration.

That is exactly the sort of quiet platform polish that compounds.