I’m working on connecting Gravity Forms data from my WordPress site to Monday.com using Make automation. Everything works fine when dealing with single entries, but I run into issues with multiple records.
My setup includes a main form with a subform component. When users submit data through the subform, the entry IDs get stored as a comma-separated string in the main form’s data bundle.
For single subform entries, I can successfully use the ‘Get Entry’ module to retrieve and process the data. However, when there are multiple subform entries in that comma-separated list, the whole process breaks down.
I’ve attempted different approaches like using repeater modules and array iterators, but none of these solutions seem to work properly. The data either doesn’t get processed correctly or the integration fails entirely.
Has anyone dealt with similar challenges when processing multiple subform records? What’s the best approach to handle comma-separated entry IDs and process each one individually?
Yeah, the comma-separated entry ID thing is a pain. I hit the same issue when connecting complex forms to external systems through Make. Here’s what finally worked for me: use the Split function before you try grabbing individual entries. I added a Text Parser module with Split to turn that comma string into an array first. Set the separator to comma and you’ll get separate array elements for each ID. Then use an iterator to loop through each ID and feed them into separate Get Entry modules one by one. The tricky bit is mapping the data after since you’ll have multiple bundles. I used an Array Aggregator to collect all the subform data back into a clean format before pushing to Monday.com. It’s worked reliably across different form setups, though you’ll need a few extra modules in your scenario.
This burned me hard on a client project last year. The problem isn’t just splitting IDs - Make processes each bundle one by one, so if one subform entry fails, your whole batch dies.
Error handling after each Get Entry module saved me. I wrapped each retrieval in its own route with error directives. One subform entry crashes? The others keep running.
Gravity Forms also loves adding trailing commas and extra spaces to ID strings. I clean these up with a Replace function before splitting to remove whitespace and empty elements.
The real game changer: parallel processing instead of sequential. Run multiple bundles at once rather than one after another. Cuts processing time in half and stops timeout issues on forms with tons of subform entries.
For Monday.com, I batch the final data push. Instead of creating items for each processed entry, I collect everything first and send one API call. Way more reliable.
had the same issue last month! fixed it by adding a webhook module right after the split function. instead of cramming everything into one scenario, i made a separate webhook that processes each entry ID one by one. main scenario splits the comma string and triggers the webhook for each ID. the webhook does the work - grabs the entry, formats it, sends to monday. much cleaner than juggling multiple bundles in one flow and won’t timeout on big batches.
That split approach works but gets messy fast with complex subform data. I’ve been there - spent way too much time debugging array mappings.
Make wasn’t built for nested form data like this. You get these complicated setups that break whenever Gravity Forms updates something small.
I switched to Latenode for this exact problem and it handles multiple subform entries perfectly. It’s got built-in logic for comma-separated values and auto-iterates without extra modules.
What I love is the conditional processing for each subform entry while keeping the parent form relationship intact. No array aggregators or complex mapping needed.
When pushing to Monday.com, Latenode’s rate limiting and error handling crushes Make’s. Saved me about 10 hours of troubleshooting on similar integrations.
Been dealing with this same issue for months across multiple client projects. Make treats each bundle separately, so multiple subform entries fragment your execution flow. Here’s what fixed it for me: I added a custom JavaScript module between the split and iterator steps. It validates entry IDs and filters out empty or malformed ones before they reach the Get Entry module. Gravity Forms sometimes throws blank entries or spaces into that comma string, which breaks everything. The JavaScript checks each ID format and removes problematic entries. Then I use a Sleep module with 1-2 second delays between API calls - without this, you’ll get random failures on larger batches due to rate limiting from both Gravity Forms and Monday.com APIs. For Monday.com specifically, batch your processed subform data using Collection modules instead of sending individual items. This cuts down API calls and prevents duplicate board items when the scenario re-runs after errors.