In the Summer ’26 Release, Salesforce is changing how custom Apex classes are instantiated when called from Flows. If you don’t want to wake up to dozens of panicked Slack messages in late May because renewals aren’t generating, integrations aren’t working, or stamps aren’t stamping, this is a Release Update to pay attention to.
In this guide, we’ll break down what’s changing, why it’s happening and what your admin team can do today to ensure there are no interruptions.
1. Current State
To set the stage, let’s break down the literal meaning of the eloquently named “Enforcing No-Argument Constructor on Apex Classes Used for Invocable Action Parameters” update.
“Invocable Action” in this context simply means an Apex resource being called by a Flow. This is done when a Flow uses an Action node to call Apex that is denoted with @InvocableMethod & @InvocableVariable annotations.
A constructor in Apex is a special method that creates a new instance of the Apex class in memory. “No-Argument”, simply means that the constructor in question doesn’t require any data (called parameters) to be passed into it in order to get started. If you write a class and don’t include any custom constructor, Salesforce is smart enough to create a hidden “no-arg” constructor for you. However, if you add a custom constructor with parameters, this hidden default constructor is deleted.
2. What’s Changing?
This brings us to what’s being enforced starting in Summer ‘26. In order to facilitate Data Cloud and Agentforce data volumes, Salesforce will no longer “guess” as to what data needs to be passed by the Flow into custom parameters for invoked Apex constructors. This means any invoked Apex without a no-argument constructor will fail to instantiate at runtime. Since the default ‘hidden’ no-argument constructor is deleted if your class has a custom constructor with parameters, the update you must make is to ensure any invocable Apex that has a custom constructor with arguments also has a custom no-argument constructor.
So now we understand what we’re dealing with, how do we identify the classes we need to update?
3. Identifying the Risks in Your Codebase
Creating custom constructors with parameters has been a general best practice when developing in Salesforce, so don’t get mad at your developers, but these classes will need to be updated before Summer ‘26.
Here’s how Ateko recommends finding these cases in your codebase.
- IDE Audit
Start by identifying every Apex class that interacts with Flow. Open your IDE (like VS Code) and perform a global search for the @InvocableVariable annotation. This will give you a list of every class currently being called from Flows.
Comb through these classes to ensure that any wrapper class with an argument constructor, also has a no-argument constructor. Here’s an example of how you would make that change to a ‘Request’ class:
- Diagnostic Testing in Sandbox
In a sandbox environment (preferably a partial or fully copy):
- Navigate to Setup > Release Updates.
- Locate Enforcing No-Argument Constructor on Apex Classes Used for Invocable Action Parameters .
- Activate the Test Run in a refreshed Sandbox.
- Execute your primary end-to-end Flow tests. Any failures here will pinpoint exactly which classes need a developer’s attention.
- Managed Packages
Because clients are unable to edit the Apex code of managed packages installed via the AppExchange, if a third-party app hasn’t updated its code to include these constructors, you’ll see errors that you cannot fix yourself.
If you come across any failures resulting from a managed package during your testing, be sure to reach out to the provider and confirm when they plan to update the package. Yet another reason to start your audits early!
- Standardizing Your Apex Patterns
As a best practice, instruct your development team to include a public no-argument constructor in all inner classes used for Invocable Actions moving forward. Standardizing this pattern now prevents technical debt from accumulating in the future.
4. Start Today!
Developers, mechanics, and doctors all agree that maintenance is cheaper than repair. Waiting until May 2026 to address these constructor requirements will likely result in severe service disruptions and a stressful beginning to your summer.
By auditing your @InvocableVariable classes today, you can get ahead of the panic and ensure your 2026 roadmap stays on track without any unexpected detours.
Is your team prepared for the Summer ’26 enforcement? If you need assistance auditing your codebase or managing your release cycle strategy, Ateko is here to help. Contact our team of experts today.
