Deprecated legacy workflow retained for existing canvases only. A Batch frame's properties panel sets how many times the interior runs (item count), how short lists behave (clamp vs cycle), and which interior input each per-item value list feeds. Build every new repeated row workflow with List Iterator instead.
Where: Batch frame → properties panel — Tune the repeater: count, length policy, and per-item inputs
Key ideas
- Deprecated—do not use for new work: Group Repeater, loop groups, Group Batch mode, and legacy Batch frames have been replaced by the source Items List → body → Results List pattern.
- Compatibility is read-only guidance: The legacy frame, its bindings, previous-results feed, and run controls are documented only so an existing canvas can be understood, repaired, and migrated without losing behavior.
Steps
- Do not create this workflow for new work. Open the List Iterator guide and build a paired source Items List and Results List instead.
- Use these legacy controls only when an existing canvas already contains the deprecated frame and must be inspected, rerun, or repaired.
- Record the old source rows, shared and per-item bindings, typed outputs, earlier-results dependency, nested scope, and result-history behavior before migrating.
- Rebuild the workflow as source Items List → body nodes → Results List, connect it with List Iterator, compare a small run with the legacy output, and remove the old frame only after the results match.
Legacy MCP tools
create_batch, create_loop_from_prompt, derive_items_for_loop, set_batch_bindings, run_batch, and create_group with is_loop=true exist only for old canvases. MCP hosts and the Flowgen assistant must use create_list_iteration, set_list_iteration, run_list_iteration, and select_list_history for new work.
Limitations and important notes
- Deprecated: no new authoring should depend on Group Repeater, loop-group, or legacy Batch controls.
- Compatibility is preserved for existing canvases; migration is deliberate rather than automatic.
FAQ
What's the difference between a per-item input and just wiring a node into the batch?
A plain wire into an interior node is a broadcast input — read live the same way on every iteration. A per-item binding turns one input into a list so each iteration gets a different value; only per-item sources determine the item count N.
My batch ran fewer items than my list had — why?
With clamp length policy, a binding stops at the end of its shorter list, so N is governed by the source lengths and policy. Switch to cycle to wrap shorter lists, or set an explicit Count to force the number of iterations.