Best answer

Many problems with new GravityForms/Zapier integration

  • 18 April 2021
  • 5 replies
  • 566 views

Userlevel 1

As others have mentioned on this forum, the new GF ↔ Zapier integration is a total mess for some of us that relied on the existing APIs.

In particular, the seeming requirement to have a 1-1 correspondence between a given form and a Zap has caused so many headaches. (We used to be able to have dozens of forms reference the same Zap’s webhook, but now these are all “managed” and as far as I can tell the 1-1 correspondence is forced; the benefits for Zapier to artificially increase Zap count are obvious.)

Besides all of that, and after moving to the next Zapier billing tier in order to get the unlimited zap count we would need to migrate our existing forms to use the new API/plugin pairings, I’ve still been unable to establish a workflow that is suitable for our (non-technical) content/form authors on the front-end side of our site’s content management.

The previous workflow was that a form author would clone a master template, make some minor cosmetic changes, and put the appropriate webhook link in the Zapier plugin config for GravityForms -- and that’s it.

Under the new workflow, as far as I can tell, since a new Zap must be created for each form, there’s no simple way to have the content authors pick from a small set of existing appropriate Zaps.

If anyone knows how this can be done with the current disaster that is the new GF WP plugin / Zapier API pairing, I’d love to hear it.

In the meantime, recreating the extensive logic for each of the different form types on a per-form basis is, quite frankly, not viable and will likely lead to us exploring alternatives to GF and/or Zapier altogether if we can’t find a workaround.

I’ve been trying quite hard to find such a workaround: my requirements are that the non-technical users must be able to -- with a fairly minimum amount of fuss -- create a new Zap for a new form and hook it up to an existing Zap. “Too much fuss” includes the need to provide field mappings or other binding of form inputs to another Zap, so as far as I can tell, SubZaps are also out of the question.

So here’s where I’m currently stuck. I thought that what I’d do is take a Zap for the complex and multi-step form processing logic and make it triggered on an incoming webhook request using “Catch Raw Hook”. If I can get that to work correctly, then the non-technical form authors can be instructed to (1) create/clone a form; (2) select the GF form submission trigger; (3) send a webhook w/ data pass-through to the “Catch Raw Hook” webhook that would take care of everything else. Even that much is not ideal, but at least it’s something that they can do in a few seconds and it’s something that I can document for them.

However, I’m currently running into the following issue. The raw payload that currently arrives at the “Catch Raw Hook” trigger looks like this:

raw_body
{'Form ID': 126, 'Form Title': 'Some Form', 'Entry ID': 0, 'Entry Date': '2021-04-17 22:02:58', 'Transaction Id': '1234567890', 'Payment Amount': 100, 'Payment Date': '2021-04-17 22:02:58', 'Payment Status': 'Paid', 'Post Id': 1, 'User Agent': 'Zapier', 'Salesforce Campaign ID': 'Sample value', 'Problematic Field': 'Some \"String\"', ... (many more fields) ...
}

...which I’m then trying to parse and extract what I need for the downstream logic via a “Run Javascript” action.

However, the above is not valid JSON! I.e., JSON.parse() will obviously fail on it, due to the use of single quotation marks instead of double quotation marks.

I’ve seen some other forum posts attempting to deal with similar issues of malformed JSON, and the suggested was to globally replace ‘ with “ -- but of course this is not a viable solution, because doing so blindly has the possibility of mucking with the field values which contain escaped double quotes and the like.

Does anyone happen to know of a JS library or some other mechanism that is capable of dealing with this kind of malformed input, or know why it’s malformed to begin with? Note that if I don’t use “Catch Raw Hook” but instead a normal webhook trigger, and then also selected data pass-through at the sender, I get no input whatsoever shown besides an empty querystring field. Awesome.

I can write an ad-hoc parser and iterate on it to eventually make something work, but it’s brittle and I’d need to do it for multiple such forms -- so the thought of having to do so is enough to make me want to look for alternate solutions (or alternate services altogether) instead, so this is sort of my last-ditch effort to see if I might be missing something obvious before I undertake dropping the GravityForms/Zapier pairing altogether.

Any insights or suggestions are greatly appreciated.

icon

Best answer by berd0029 23 April 2021, 04:31

View original

This post has been closed for comments. Please create a new post if you need help or have a question about this topic.

5 replies

Userlevel 1

Just some feedback, but I think you’re going to have a hard time getting help with your question because it doesn’t make a lot of sense.

You probably need to give a little bit more context on what you’re trying to accomplish.

Maybe you’ve already tried this, but I personally have been using the standard gravity form webhook addon instead of the zapier addon. Then sending that to a standard zapier webhook receiver.   The zapier → gravity and gravity → zapier addons aren’t working great… but the standard webhook stuff is fine.

 

Also, you don’t have to create a new zap for each form if you’re using standard webhooks, and even using the direct integration you can rename the zap webhook to whatever you want in gravity forms…



Hope that helps
 

Userlevel 7
Badge +14

Hi @azcwebmanager 

Here’s the Gravity Forms Webhooks add-on that was mentioned:

https://www.gravityforms.com/add-ons/webhooks/

 

Zapier Webhooks: https://zapier.com/apps/webhook/integrations

Userlevel 7
Badge +10

@azcwebmanager 
Just checking in to see if you still need help with this? 

Userlevel 1

@AndrewJDavison_Luhhu I think I’m good for now, thanks much!