Outbound Webhook JSON: improve UX/DX by providing advanced parsing/data wrangling

[I-Dont-Remember]

Original title: Better UX for multi-line/list data in Outbound Webhook JSON. Updated to reflect the base feature was added, but now this issue can track other enhancements in the same vein.

A fairly common use case is to ask users for a list of 0-many items in a form, which can then get sent via webhook to Zapier, Make, etc. Many people accomplish this with a multi-line text input and then ask users to put each item on a newline, .e.g:

https://example.com/abc
https://example.com/123
https://example.com/def

See screenshot of example. This variable will then show up in your JSON as string with \n separating each item:

{
    "key": "https://example.com/abc\nhttps://example.com/123\nhttps://example.com/def"
}

Is there a benefit to us providing an option to convert these string lists into true JSON lists? How might we provide this configuration in a way that provides value to users?

{
  "key": [
    "https://example.com/abc",
    "https://example.com/123",
    "https://example.com/def"
  ]
}

[I-Dont-Remember]

One potential solution: provide another boolean Flag option for convert keys with newlines into lists - that would be simple enough to check for. User experience wise, it does mean they wouldn't have control at a granular per-key level to switch it on and off. Having one key with newlines they want to keep and one with newlines they want as a list is a very niche use case, considering we're already talking about a very niche use-case to start with.

[jphorn]

I think the Outgoing Webhook option (or WF Buddy in general) in itself is heavily geared to devs/tech savvy users anyway, so this option seems fine by me, as opposed to getting the result in a single value with control chars like \n or \t.

If we have clarity what output to expect, we're able to work around it either way. Considering the targeted audience and the niche use case I guess a proper json list is easiest to process further down the chain (e.g. Make/Zapier/own API) instead of having to fiddle with parsing control chars. Also because it's fairly easy to concat a json list. So I'd say to ditch the granular level of control.

But... maybe it'd be feasible to use the first line for multiline inputs as a configuration, e.g. [list] or [blob] and then have WF Buddy check if one of these values exists as return value and then let WF Buddy do its own parsing to correctly return the output. If neither value exists as first line, than just return the form field as single blob. That would allow for granular level and negates the need for a boolean flag.

[I-Dont-Remember]

Discussed externally - the idea above has some good direction, but in the current form would move onus of control from person building Workflow to the person providing data input - harder to control. BUT I like where the idea is headed. Also depending on the users, might not be that hard to get people to be "trained" to do it right, so might still be viable.

🧠 One use case for idea could be when the workflow designer is putting together the JSON body, have a block at the top we reserve for "advanced flags". Could be an interesting way to expose more capabilities without cluttering up screen with tons of checkboxes.

[I-Dont-Remember]

Another potential approach: use special characters in the name of a field to indicate action should be taken. Zapier has it so any field prefixed with __ wll be "unflattened" into nested dictionaries (see image). We could do something similar where if a field is prefixed with [] (or better chars :D ) then we will convert any newlines into a list. Then this stays under control of the Workflow builder

[I-Dont-Remember]

Now that we have ability to do __ to have Buddy wrangle the data into a list, it opens the door for other future prefix combos to do creative things that I don't know yet -- leaving this issue open as those potential features arise!

[jphorn]

Hi. I ran into another issue with multi-line form input, where JSON trips over certain characters. One was very easy to find, but also extremely common: use of quotation marks in the full body. I guess these need to be escaped?

The other one I'm having a really hard time to dissect, because Slack/Workflow Buddy error output isn't showing me the right line. I can give you the examples privately via Slack.