Webhook not triggering when submitting survey from Experience Builder application

[DavidPena]

Hello,

I have configured an Experience Builder application which includes a survey form for reporting outages. The survey has a webhook configuration which is supposed to trigger the creation of jobs in Workflow Manager. The survey is working as intended when editing features through the form, however, the jobs are not created. When completing the form outside of the EB application (via the field app or web app) the webhook works and the jobs are created.  Unfortunately this only seems to work when the survey is creating new features - for our use case we only want to edit existing features. I added a URL linking to my form to complete it from the S123 web app, but when adding all the parameters, I get the following error and the submit button is disabled:

Editing is not possible because the globalId parameter was not provided.

I have used the URL configuration successfully before with Field Maps and never encountered this error. Ideally the webhook would work straight from the EB app, but getting the URL to work would be a fine workaround for the moment.

Any thoughts or help is appreciated.

[abureaux]

When working with webhooks, you need to ensure that you have manually checked off "Existing record edited"

If you don't check this option (manually), your survey submissions will only trigger from new submissions and not editing an existing form.

EDIT: and regarding that error message (which I believe is a separate issue), check out this thread.

[DavidPena]

Hi, thanks for your response. Both boxes are checked in our webhook. Sorry for not making that clear in my post.

I believe I already went through the linked post, but I will go through it again and see if there's anything I missed.

[abureaux]

Assuming you only have the one webhook for that survey, are you sure the survey in Experience Builder is connected to the proper survey? (I.e., can you do a new submission from Experience Builder and see that record in the proper Feature Layer?)

I see no other reason for survey submissions through EB to not trigger a webhook.

EB's survey widget is a lot like the web interface, in that each time it's loaded, it downloads updates. This is (annoyingly) contrary to the Field App version that only checks for updates at specific times. After adding a webhook to a survey and prior to submitting from the Field App, you are required to manually check for and download the newly pending update. Without this aforementioned update, submissions from the Field App will not trigger a webhook. But this shouldn't be an issue for EB (you can always try reloading the web page though).

[DavidPena · Accepted solution]

Abureaux,

After much testing and troubleshooting, we found a documentation that notes that the functionality we're looking to implement is not supported at the moment. Workflow Manager only supports creating jobs when submitting new records with a survey, but not when editing an existing record.

We'll rethink our solution.

Thanks again

[abureaux]

Good to know! Hopefully they remedy that soon.

Is this a public survey or a private survey? If this is a private survey (or even one where you don't mind the survey responses being exposed), I do have a workflow that targets the Feature Layer directly and ignores webhooks. It is super helpful for more mission critical workflows as it bypasses the webhook's limitations and bugs entirely.

[RobertAnderson3]

Is this workflow specifically for Workflow Manager or just Survey123 and targetting the feature layer skipping the webhooks, because I'd like to jump past those limitations as well haha, and our dev team is too busy to get to the API tools to fix a process that works 99% of the time right now.

[abureaux]

The workflow I described is specifically a replacement for for the Survey123 When a survey is submitted trigger (this includes both new and edit submissions). Rather than watch for a survey submission, I monitor the Feature Layer directly and process based on that.

Since you are monitoring a Feature Layer, I'd recommend only doing this where either the data is secured with accounts, or the data isn't private/confidential. Unfortunately for me, a bulk of my forms can't support this flow. If they did, I would 100% scrap every flow with the S123 trigger in favour of this model. If you'd like, I can put together a quick guide.