Jotform > Zapier > QUE Comp Swapping

[eric_dean]

Can it be done? Zapier uses double curly braces for its own under-the-hood purposes, so doesn’t interpret data enclosed in double curlies as strings to be passed along to QUE. I realize that this is a problem with Zapier rather than Dataclay per se, but I’m wondering whether anyone has devised a clever workaround, since without the comp swapping functionality, the integration is useless for my application.

[ariestav]

@eric_dean Thanks for pointing this out. It’s an interesting question because wrapping identifiers within braces is a common practice — which is why we decided to go forward with using that type of notation. Does Zapier ever “see” the double-braces as part of the string at any point it’s its process? Is there any way you can log the raw data that Zapier receives from your Jotform? If so, you might be able to URL encode the double braces for the transmission Zapier performs to QUE.

Any chance you can show an example of what the raw data looks like coming from Jotform to Zapier before it processes it for any purpose?

Thanks!

[eric_dean]

@ariestav Thanks for chiming in! Short answer: yes, Zapier sees the double braces as part of the string until sometime at the end of the process. Here’s the window showing the Jotform record it’s using to test:

Based on a 2 year-old suggestion from a Zapier forum in response to someone who had the same trouble with braces while implementing a Google Sheets integration, I then had Jotform send over square brackets, and set up Zapier “Formatters” to find and replace with braces. Here you can see that right up to the final “Insert Job in Dataclay QUE” step of the Zap, it’s behaving as hoped:

Between here and QUE, though, it just disappears!
In one variant of the test, I accidentally replaced only one set of brackets with braces. In the job properties window on the QUE web dashboard, this appeared exactly as expected. (“[[01_Image}}”) But once the formatters were fixed, it was gone again!

[ariestav]

@eric_dean You may want to try setting it up so that the Zapier formatters replaces the square brackets with the URL encode of braces.

The encode for open brace character { is %7B
The encode for close brace character } is %7D

Can you try using Zapier’s formatter such that [[compname]] becomes the literal string %7B%7Bcompname%7D%7D

Then, when the POST call is made to QUE, it might interpret the encoding correctly by the time it stores the jobs data into the campaign.

Please let me know if this helps.

—Arie

[eric_dean]

@ariestav Thanks for sticking with me here! By following your suggestion, we have at least gotten as far as passing that string along to QUE!

This string doesn’t appear to mean anything to Templater as received, though.

[ariestav]

@eric_dean You might need to use a custom POST call to the job insert endpoint instead of the default integration we have with Zapier. The POST call can be specified as URL Encoded so that the symbols can get transformed. We’ll need to investigate what the deal is with our custom integration, but in the meantime, can you do a custom post call with Content-Type as application/json? Here is the documentation on the endpoint you would need:

[Jon]

@eric_dean It’s interesting that you’re getting the braces from JotForm into Zapier, because that’s actually where I’m seeing a problem. On the test form I set up, it’s not sending the braces through to Zapier (No data to show for this record) for dropdowns and text fields (what I’ve tested so far), even though the data is recorded correctly in the submissions inbox. I don’t remember running into this issue when I built the integration, but I’ve found evidence (as you did) that would suggest that double braces have always been a problem for Zapier—it’s trying to interpret them as variables instead of strings. Even using the Formatter and Code steps, I couldn’t get them to output strings with the double braces the way that you were able to. I’m baffled, because I swear that this exact use-case was tested.

You could do as Arie suggested and use a Zapier Webhooks action to send the API call directly, bypassing the QUE integration. You might still run into the issue of Zapier messing with the data on any given Zap step, but the encoded entity thing might work.

[Jon]

@eric_dean We’re currently testing a fix for Templater to accept [[flags-like this]] in addition to {{this-kind}}. Fingers crossed we don’t run into any showstopping bugs. We’ll let you know as soon as we can.

One thing to note on the JotForm end is that double brackets in dropdown fields become unselectable category groups, so you have to do two extra things to get them to work with Zapier. Say you have a list of comps that you want to swap between:

• comp-1
• comp-2
• comp-3

For the dropdown field you’d want to click the “Properties” gear then go to the “Options” tab in the sidebar. Lower down, turn on “Calculation Values”, and for each value, enter the “flagged” version of the string.

• [[comp-1]]
• [[comp-2]]
• [[comp-3]]

Then you’ll want to add a “Form Calculation” Widget from the “Form Elements” menu. In the “Widget Settings”, add your field
in the Calculation field in the sidebar, and make sure it’s set to “string” rather than “number”. Be sure to save.

You can then open the widget’s Properties, and on the “Advanced” tab, you can enable the option to “Hide field”.

Once you do this, the data should be mapable in Zapier’s action step for QUE.

[eric_dean]

@Jon This is amazing. I feel a certain perverse pride over having found this rabbit hole and sent you down it. Looking forward to hearing about your progress with the fix!

Thanks for the Jotform pointers, too! I hadn’t even explored this idea. My duct-taped-together workflow was to set up two hidden text fields containing, respectively, {{01_image}} and {{01_video}}. Then I added a third hidden text field called 01_footage, and rigged conditionals on the back end to populate that field with the default text from one or the other of the first two depending on the client-facing dropdown menu. Templater gets the contents of 01_footage, and Bob’s your uncle. This is the kind of overly elaborate problem solving you end up with when you have no idea what you’re doing. Your suggestion looks much more elegant to me, especially as the finished product I’m working toward requires five of these!

Right now we’re using Jotform’s native Google Sheets integration to pass data to Templater, alongside a Zap that moves client-uploaded images and video into a footage folder on Dropbox for me to target. Since our current concept still involves doing these one at a time with a certain amount of personalized attention required, this will suffice; I don’t need to be able to automate a batch process. But if you get your fix running, it will still probably make sense for us to work through QUE instead. Keep me posted, and thanks so much again!

[Jon]

@eric_dean shoot us an email at support@dataclay, and we’ll send you a build that should work with the new flags. Also, let us know which platform (MacOS or Windows).