I've set up a GET API call to Circle.so to fetch new or updated subscription members. The API call is successful and returns 26 bundles in an array. I then added an Iterator module, which correctly splits the array, yielding 26 bundles with all the expected data. Following that, an Airtable Search Records module appears to function correctly, showing the expected 26 records in its output, matching my 26 subscribers. However, there's only one existing row in the Airtable record being searched. Finally, I'm using Airtable Upsert. I've mapped the Airtable Record ID ("ID") and then mapped all the Iterator output fields appropriately to the target table for the "Upsert" operation. Despite this, when I run the scenario, only Row 1 in the table gets updated, repeatedly. It processes all 26 records, modifying the information in Row 1 each time, until it completes all 26 iterations. The data from the last processed bundle is what remains. What might I be missing?
When asking your question, please include:
The steps you have taken
Relevant screenshots
Any links you have
[ Code { "and": "JSON", "in" : "code block"} ]
Exclude Personal Information.
Could you please share a screenshot of the final module settings, specifically for the Upsert configuration?
Another peculiar behavior I've observed: When I implement a router with a path for creating records and another for updating records, and then configure a filter based on whether an Airtable record ID exists or not, it seems to behave unexpectedly. Even after I delete all records in the table, the system acts as if the record still exists, directing the flow to the update branch. It appears to be checking for the existence of any record and then repeatedly updating that single record, rather than matching each iteration's ID against the table to determine if that specific record exists.
This is unusual, and I'm not sure what's causing the issue with the scenario. Could you please examine the execution log to verify if the correct Record ID is being passed to the Upsert operation?
Yes, this is quite unusual. From what I can tell, the correct record ID is being supplied.
Regardless, the behavior of repeatedly overwriting the same record is strange; I suspect there's an issue with the filter configuration or something similar. Thanks for taking a look.
Hi, were you able to find a resolution for this? I'm encountering the identical issue right now…