Fifty records in, one row out: inside the loop vs after it

You pull fifty records from an API. You run the workflow. It goes green — no errors, no warnings, nothing red anywhere.

One row lands in your table. Not fifty. One.

The bug isn’t in your mapping, and it isn’t the API. It’s a position: the write step is sitting after Iterator End instead of inside the loop, so it ran once — with whatever the last pass left behind.

The rule, up front

Everything between the Iterator and Iterator End repeats, once per item. Everything after Iterator End happens once. That’s it — and it’s the whole difference between fifty rows and one.

• Inside the loop: writing rows, a message per person, an API call per record.
• After the loop: counting, summarising, one notification, one file.

Seven steps that use both sides

1. Schedule → Every Day — it has to happen without you.
2. API by FlowMattic → GET — fetches the records.
3. Iterator → Loop Through Array — walks the returned array.
4. WP Tables → New Record — inside the loop. One row per record.
5. Iterator End — closes it.
6. WP Tables → Get Row Count — after. Runs once.
7. Slack → Send Channel Message — after. One message, not fifty.

Steps six and seven aren’t filler. They’re the proof: the same rule that breaks step four is exactly what makes those two correct.

Pointing the loop at the array

An array is the thing the Iterator eats. If your API hands you one, you’re already most of the way there — point Iteration Array at the response from the API step and everything down to Iterator End runs once per record.

Leave Simple Response on so each item’s fields are flattened into the picker, and leave Iteration Processing Method on Direct — one pass, straight through. Batch is for the day you’re looping hundreds of items and the server needs room to breathe.

Mapping the current record

In the WP Tables step, pick the database and table, then map each column to the item you’re on right now — not the whole array:

Name    {iterator3.name}
Email   {iterator3.email}
Ticket  {iterator3.ticket}

The 3 is the Iterator’s step number. Tokens follow the app slug and the step it came from, which is why the same field looks different if you move steps around.

Watch it built

The whole workflow, the config screens, and a run of fifty in under four minutes:

The step that tells you the answer

Iterator End spells it out in its own warning box: “This action will end the iterator execution at this step. Next steps will be executed after the iterator is fully executed.”

Read that before you place a step, and you’ll never have to debug this one. Above it repeats. Below it runs once.

Why the last two steps go after

Get Row Count wants to know how many rows exist now — one answer, after everything is written. Slack wants to tell your team the import finished — one message.

Put Get Row Count inside the loop and you’ll count the table fifty times. Put Slack inside it and you’ll be extremely unpopular by lunchtime. Same rule, opposite side.

The one decision

Per-item work goes inside the loop. Once-only work goes after it. Get that right and the Iterator stops being confusing. Get it wrong and everything still runs — quietly, incorrectly, with a green tick on top.

New to FlowMattic? It’s the AI-native automation platform for WordPress — visual workflows, 900+ integrations, AI agents and a full builder suite, self-hosted inside your own dashboard. Get FlowMattic.