Looking for a method, whether it be a service/plugin/add-on/script that can perform a daily check of all Gravity Forms for new submissions, then run through the arrays per form id looking for and collecting instances of ‘[field name]’ => $entry[’[field id#’] and then save to a table in the database.
You can do this as each form gets submitted using Zapier. You set up your db tables, then set up a Zap to add the info you want into those tables each time a form is submitted. There may be plugins or other ways but this is how I’ve done it and it works great.
Why not send the submissions to Google Sheets as they happen, rather than on a schedule every day?
There are a couple ways:
Thanks for your answer!
We’ll try Zapier and see how it goes.
Thanks for your answer,
We could do that but we’ll have to figure out how to link the spreadsheet to our middle-man database, and then post from this database to our CRM.
The whole workflow we’d like to set up is
- User submits form
- Submission entry is stored to WP data base
- These submissions are scrapped on a regular basis (or as we received them) and posted to a middle-man database
- Our CRM, scraps the middle-man database and updates the relevant properties
Thanks for your input nonetheless.
What CRM are you using? Because there are a few CRM Add-Ons available for Gravity Forms and Zapier can link GF to even more CRMs
It’s a custom built system
Appreciate the thought.
Okay, so if I’m not mistaken (re-read the topic again) you’d like to add GF entries to a separate table so that can be scraped on an interval. I’m guessing the separate table is some kind of fail-safe to make sure edits aren’t done on the CRM directly?
Anyway, you should be able to add new entries to a separate table (or database) as they’re processed:
WP-Cron (which I’d disable and setup as an actual cronjob) could be used to remove the old ‘new entries’ on a daily basis to make sure the table doesn’t have older entries in them. Perhaps right after pushing them to the Custom CRM. Or if the custom CRM contacts the ‘middle man’ table: make sure it fires an “empty when done” action (although it’d probably be a better idea to check what the latest unique ID in the table was and make sure to not remove anything above that ID).
Without knowing actual specifics it’s kinda hard to advise, but perhaps the above does help in finding (or making ) a solution