Use a paired source Items List and Results List for every new repeated row workflow. Group Repeater, loop groups, and Group Batch mode are deprecated and remain available only so existing canvases can still run or be repaired.
Where: Flowgen → Add → Inputs → Items List → Repeat these items → Set up
Before you start
- At least one non-empty source row.
- A paired Results List with at least one collected output field.
- Source and Results Lists must live at the same group boundary.
Key ideas
- List Iterator is the supported replacement: A source Items List supplies typed rows, the connected body runs once per row, and a Results List collects exact typed outputs in source order.
- Group Repeater is deprecated: The older loop-enabled Group—also called Group Repeater, Loop Group, or Group Batch—must not be used for new work. Its controls and MCP tools remain only for backward compatibility with existing canvases.
- Two Lists define the repeat boundary: The starting Items List provides rows and a paired Results List collects them. The Set up action creates and connects the Results List; nodes placed between the pair are the body that runs once for every source row.
- Rows are isolated runs: Each source row receives its own prompt and typed field values. A result or failure from one item does not silently become another item’s input, and concurrent work does not overwrite shared node state.
- Typed source and result fields: Every source column exposes a typed Current <field> output for the active row. The Results List can keep selected source fields and collect exact body outputs into text, image, video, audio, mask, dataset, HTML, 3D, or other compatible typed columns.
- A complete-set barrier: Downstream consumers of the Results List wait until all source rows have settled. Completed, failed, and cancelled rows retain source order and diagnostics, so the table remains aligned instead of shortening unpredictably.
- Append, Replace, and completed history: Add each run appends a new completed set below earlier results. Replace swaps the visible set only when the next run finishes. Previous results exposes retained completed snapshots; the current partial run is deliberately excluded.
- Refresh is explicit: The source List only regenerates from its AI brief before an iteration when Refresh items before Play is on. Manual mode always repeats the rows currently shown.
- Group Repeater and Batch authoring are deprecated: All new repeated row work belongs to paired source/Results Lists. A Group is visual organization, reuse, mini-app, and publishing—not a repetition mechanism. Existing loop-enabled Groups and Batch frames remain runnable only for compatibility.
Steps
- For new repeated work, add an Items List and define one typed column for every value that changes per row.
- Choose Repeat these items → Set up, or use the create_list_iteration MCP tool. Flowgen creates or pairs a Results List.
- Place the body nodes between the source and Results Lists, then wire Current <field> outputs into the exact inputs that vary.
- Wire exact body outputs into typed Results List columns; choose Add each run or Replace and select any source fields to retain.
- Run the source List or call run_list_iteration. Do not convert a Group into a repeater and do not create a new Batch frame.
- If an older canvas already contains a Group Repeater, keep it runnable while you work. Migrate deliberately by recreating its source rows, per-item input mappings, result mappings, history needs, and nested scope as a List Iterator before removing the old frame.
- Place or connect the body nodes between the two Lists. Wire each Current <field> output from the source List to the exact body input that should vary per row.
- On the Results List, drag the final body output onto + Add output field to create a correctly typed result column, or define and wire several output columns explicitly.
- Choose Add each run or Replace. Under Keep input fields, select identifiers, prompts, filenames, or other source columns that should remain beside each result.
- Run the source List. Watch completed/total progress and any failed count; use Cancel to stop the still-pending items when needed.
- Inspect every Results row, including empty cells and diagnostics on failed/cancelled rows, before sending the whole list downstream.
- When a later run needs earlier completed context, connect Previous results to Extract / Merge and choose Latest, Last 3, All saved, or a more exact MCP history selection.
- For a nested workflow, create another source/Results pair inside the outer body and test a tiny dataset first; the Nested marker identifies the inner repeat scope.
- Before running the pair, confirm the source List is Manual for curated rows or Refresh for hot AI regeneration.
- Use List Iterator for every new “one row through connected steps” workflow. Never create a Group Repeater, loop-enabled Group, or Batch frame; inspect or repair those only when an existing canvas already contains one.
- Test a three-row List with visibly different inputs, inspect three collected results and separate saved files, then increase the batch size.
Names that refer to the deprecated workflow
- Group Repeater
- Loop Group
- Loop-enabled Group
- Group Batch mode
- Legacy Batch frame
MCP and Flowgen assistant rule
New workflows use create_list_iteration, set_list_iteration, run_list_iteration, and select_list_history. create_batch, create_loop_from_prompt, derive_items_for_loop, set_batch_bindings, run_batch, and create_group with is_loop=true are legacy compatibility tools and must not be selected for new work.
Roles are inferred from the graph
- Plain Items List: editable records with no repeat boundary.
- Source List: its each_out reaches a Results List collect_in.
- Results List: receives collect_in and blocks downstream until the set settles.
- Source + Results: a List can collect an earlier repeat and start another, enabling a pipeline of repeat stages.
Source outputs and collection inputs
- Current item / items_out — the active row as one record.
- Current <field> / col_<id> — the active typed cell.
- All rows / rows_out — the complete table outside the per-item path.
- Repeat each / each_out → Save results / collect_in — the control boundary.
- + Add output field / add_field_in — creates a typed result column from the dropped output.
- Previous results / history_out — selected completed snapshots only.
Collection behavior
Add each run is the default and preserves earlier rows. Replace keeps the last complete result visible while work is running, then replaces it atomically when the new set settles. Keep input fields copies the selected source cells into each collected row before result values are added.
MCP authoring
- create_list_iteration — create/reuse the two Lists, schemas, rows, and exact bindings.
- set_list_iteration — update append/replace, kept input columns, or result bindings.
- run_list_iteration — run and wait for the complete-set barrier.
- select_list_history — choose previous, last-n, pinned run, all, or matching keys/rounds.
Current-graph execution
The pair and its dependencies resolve from the current nodes and edges at run time. Fresh upstream dependencies complete before row values are folded into the iteration, and the Results barrier releases only after every current row settles.
Current List execution and connected-item behavior
List repetition uses the active row’s resolved inputs for both generation and deterministic editing nodes. Results collect incrementally, and per-row files get distinct identities instead of repeatedly overwriting one node output. The connected table preserves useful ordering, and specific cell mentions resolve the selected cell rather than an unrelated whole-list value.
- AI Fill controls are shared and distinguish manual execution from refresh/regeneration of unlocked items.
- List/Grid/Carousel are presentation choices, not different execution engines.
- A detached extract-to-input action keeps a fixed item; a connected Extract/Transform continues following the List.
- Independent groups can run while another group is still active; this does not waive each run’s input requirements or paid-action gates.
Tips
- Keep a stable ID/SKU/source-name field so results can be traced even if a body node fails.
- Collect several small typed outputs rather than one opaque JSON blob when later nodes need only one field.
- Use shared context connections for constants; put a value in the Items table only when it truly varies by row.
- Start with two or three rows, especially before nested or expensive video workflows.
Limitations and important notes
- A Results List without an output field cannot preserve a useful body result.
- The two boundary Lists cannot be the same node and cannot cross different group owners.
- Previous results never exposes the current in-progress rows; this prevents self-feeding partial batches.
- Failed/cancelled rows preserve alignment but their missing required outputs remain empty and diagnostic.
Troubleshooting
Set up or Run says the repeat relationship is invalid
Confirm the source each_out connects to a separate Results List collect_in and that both Lists share the same parent group or both live at the top level.
Every row used the same prompt or media
Wire the source List’s Current <field> output to the body input. A shared upstream wire intentionally broadcasts one value to every item.
The run completes but the Results List is empty
Connect the final body output to + Add output field or create a result column with the matching type and wire the exact source handle into it.
A second run erased the first one
Choose Add each run before the next run. Replace is intentionally a latest-complete-set view.
A nested iteration appears stalled
Inspect the inner Results List first. The outer row cannot settle until its nested complete-set barrier finishes or is cancelled.
FAQ
Should I use a Group Repeater or Batch for a new workflow?
No. Use List Iterator. Plain Groups are still supported for organization, reusable typed sockets, nested subflows, mini apps, and publishing—but not as the repetition mechanism.
Will an existing Group Repeater stop working?
No. Existing legacy flows remain inspectable and runnable. The deprecation prevents new authoring and gives you a clear migration target; it does not silently rewrite or delete an existing canvas.
Can one item return several outputs?
Yes. Add multiple typed result columns and wire each exact body output handle to its own column.
Can a result become the source of another repeat?
Yes. A Results List can also start a later repeat, and nested source/Results pairs are supported.
Related guides
- Items List: typed records, AI Fill, views, and repetition
- View an Items List as a grid or fullscreen carousel
- Extract / Merge: take apart, combine, and type connected values
- Route current values through Lists and Transform
- Extract a result to its own input node
- Compare generation takes in the version grid