@Jonathan_W,
I don’t believe there is. One of the issues with Blocks is that they are like little black boxes; they pretty much conceal what’s really happening under the covers. Zapier and services like it are similar in nature - they do what they do and one of the aspects that make them so compelling is you don’t need (or want) to know how the sausage is made.
My hunch is the behavior you are seeing is intended and likely related to one of these caveats in the process:
- If the CSV file contains multiple rows which contain the same value for the merge field, the block will only use the first of those rows, and subsequent rows will be ignored.
- If the table has multiple records, all of which contain the same value for the merge field, all of those records will be updated if there’s a matching row in the CSV file.
- If the CSV contains any rows where the value in the merge field is blank, a new record will be created.
Any of these constraints could explain why the process outcome doesn’t seem right.
If you need precision updates with process rules that go beyond the standard CSV block, it might be time to build a seamless integration from wherever the CSV data is being generated. But beware - importing new records and synchronizing data are two very different ideas. At a glance, the code to do this seems pretty simple, but there are several devils in the details depending on the data, the data types, and the requirements.
