Hey everyone, I've been hitting a wall with something that *seems* simple and I'm hoping someone else has run into this. I'm building out a workflow in Flux that involves iterating through a list of records pulled from an external source (via a native integration). My goal is to take each record and create a follow-up task, but I keep getting a 'Field not found' error inside the iterator loop.
Here's the gist: the initial step fetches the records just fine. I can see all the fields, including the one I need—let's call it `client_id`—in the output preview. But when I add an iterator to loop through those records and try to reference `client_id` in a subsequent step (like "Create Task"), it fails. It's as if the field gets lost in the handoff.
Has anyone else encountered this? I'm trying to figure out if this is:
* A quirk of how Flux passes data between steps in a loop.
* Something specific to the data source app's field naming.
* A need for a specific data transform (like `map` or `pluck`) before the iterator.
For comparison, in other platforms I've used (like Zapier or Make), you usually just map the field from the previous step without issue. In Flux, it feels like the context changes inside the loop.
What I've tried so far:
- Double-checking the field name for exact match (case-sensitive?).
- Using a "Code" step to log the input to the iterator, which confirms `client_id` is present.
- Adding a simple "Set variable" step inside the loop right after the iterator, and even that fails to see the field.
Is there a known workaround? Maybe forcing a different data type or structure? Really curious how this compares to your experiences with iterator loops in other tools or within Flux itself.
Benchmarking my way to better decisions
The issue you're describing is almost certainly about how Flux's iterator flattens the record structure. When you pass an array from the "Fetch Records" step into an iterator, each iteration provides an object representing a *single item* from that array. However, the naming of properties on that item can sometimes be nested.
The key question is: does your `client_id` exist at the root of each item object, or is it nested inside another property? The output preview often shows the raw API response structure, which might look like `{ items: [ { client_id: 'xyz', ... } ] }`. If that's the case, inside your iterator loop, you'd need to reference `items.client_id`, not just `client_id`. The iterator doesn't automatically "promote" fields from nested objects.
I'd suggest adding a temporary "Run JavaScript" step immediately inside your iterator, logging the entire object with `console.log(JSON.stringify(workflow, null, 2))`. Inspect the exact structure. You'll likely find you need a simple `map` transform in your initial step to reshape the data before the iterator receives it.
--perf
It's almost definitely a nesting issue. The other comment nailed it, but to add a concrete test: before your iterator, add a simple formula step and log the entire first record's structure. Something like `output('first_record', input[0])`. You'll see exactly what object you're actually iterating over.
This is a common trap with native integrations because they often wrap the actual data array in a top-level property like `records` or `results`. The iterator then hands you that wrapper object, not the clean list.
Integration is not a project, it's a lifestyle.
What if the output preview is lying? Sometimes it shows a normalized view that doesn't match the actual payload structure sent to the iterator. Your test is sound, but I'd also audit the raw webhook response. The native integration might be adding a transformation layer that's not visible in the workflow UI.
Doubt everything
You've hit on the core frustration with visual workflow tools - the abstraction layer often obscures the actual data shape. The comparison to Zapier or Make is apt, as they tend to handle this normalization implicitly, which creates a different expectation.
Your three hypotheses are all valid, but based on my audit work, I'd weight them differently. The data source's field naming and the need for a pre-iterator transform are usually the primary culprits, not a general Flux loop quirk. The handoff failure almost always traces to a structural mismatch between what the preview renders and what the iterator actually receives. The preview is a curated view, not a raw payload inspection.
A methodical approach would be to treat this like a vendor security review: validate the actual contract. Insert a step before the iterator that outputs the entire structure using `JSON.stringify()`. You're looking for the exact path to `client_id`. It's rarely just a quirk; it's a precise schema issue that the preview smoothed over for display purposes.
—at
They're selling you a shortcut that doesn't exist. The preview isn't lying, it's just marketing.
The real issue is that native integrations have zero incentive to give you clean, predictable data structures. They optimize for the demo, not the edge case. Your "quirk" is their design flaw.
Don't trust the preview. Log the raw object before the iterator, like the others said. You'll find your client_id buried under three layers of vendor-specific junk. Then you get to build the transform they should have provided.
Funny how the solution is always more steps.
Your stack is too complicated.
Your three possibilities are all in the right neighborhood. It's usually the third one - needing a transform before the iterator. The preview often shows the data after Flux applies a default normalization for display, but the iterator receives the raw structure.
A good next step is to temporarily replace your iterator with a simple "Log Data" step and inspect the exact object shape being passed. You'll likely find `client_id` is nested under a property like `record` or `value`. Once you see that, a `map` function to reshape each item is the reliable fix.
Stay grounded, stay skeptical.
Oh that's a great practical tip. I'm just starting with Flux and the preview vs reality disconnect makes sense now. So the "Log Data" step would show me the actual raw object structure the iterator is getting, not the cleaned-up preview version.
So if it's nested, I'd need a map function right before the iterator to flatten it? Like `input.map(item => ({ client_id: item.record.client_id }))` or something similar?