Hi @matthew_hughes
Flow Designer Actions have a fixed limit on the number of inputs that can be defined. This is expected behavior and cannot be increased. When an action grows too large, the correct approach is to redesign the solution rather than trying to bypass the limit.
Below are three supported and recommended options, with detailed explanations of when and how to use each.
Option 1: Wrapper (Orchestration) Action – Recommended Approach
What this means
Instead of trying to put all logic into one action, you create a parent (wrapper) action that coordinates multiple smaller actions.
How it works
- Keep your existing actions as they are
- Create a new action that:
- Accepts a smaller, logical set of inputs
- Calls Action A
- Calls Action B
- Passes outputs from one action to the next
Example
You currently have:
- Action A – validates data
- Action B – performs updates
The wrapper action:
- Receives the request information once
- Calls Action A for validation
- If successful, calls Action B to perform the update
Why this works well
- Avoids input limits
- Keeps each action focused on a single responsibility
- Easier to test and troubleshoot
- Fully supported and upgrade-safe
When to use it
- You already have multiple actions
- The actions are reusable
- You want clean orchestration without duplication
Option 2: Group Inputs Using an Object (Payload-Based Design)
What this means
Instead of passing many individual inputs, you pass one structured object that contains all related data.
How it works
- Define a single input, such as request_payload
- Inside the action, extract the needed values from the object
- Add new attributes later without changing the action interface
Example
Instead of these inputs:
- user
- department
- priority
- cost center
- location
Use one input:
request_payload = {
user,
department,
priority,
cost_center,
location
}
Why this works well
- Dramatically reduces input count
- Makes actions future-proof
- Aligns with API and integration best practices
- Easier to maintain as requirements grow
When to use it
- Large number of related inputs
- Data naturally belongs together
- Action is reused across multiple flows
Option 3: Use Subflows Instead of Large Actions
What this means
If your logic is more about process orchestration than a single task, a Subflow may be a better fit than an Action.
How it works
- Break logic into small, focused actions
- Use a Subflow to:
- Control sequence
- Apply conditions
- Handle branching and error paths
Example
- Action: Create record
- Action: Update record
- Action: Send notification
The Subflow decides:
- When each action runs
- What happens if one fails
- Which path to follow
Why this works well
- Better readability
- Easier debugging
- Clear separation between tasks and process logic
- No pressure to overload actions with inputs
When to use it
- Complex business logic
- Multiple decision points
- Actions need to be reused independently
What Not to Do
- Do not attempt to bypass the input limit using scripts
- Do not build “do-everything” actions
- Do not duplicate logic just to avoid redesign
This response helped, please mark it as the accepted solution so others can benefit as well.
