nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How reliable are ArcGIS Online webhooks?

Bud

For example, a Survey123 webhook triggered by a feature being created, that uses Power Automate to send an email or create a feature in a different feature layer.

Can I rely on the webhooks to fire 100% of the time?

Find more posts tagged with

Accepted answers

All comments

LindsayRaabe_FPCWA

I know it doesn't seem right, but just can't make those connections stick for some reason. We do have a service account running, but our IT team haven't assigned it to myself or the person who was in the Survey1232 dev space - they're keeping control of it. Thus, any flow we create is saved against our account and shared with the service account. The IT guy then logs in and updates the email function to use the Service Accounts credentials instead of ours (as we can't send emails on behalf of anyone else). Ideally, the service account would be handed over to myself and/or the Survey123 dev to create the flows in from the get go.

LindsayRaabe_FPCWA

Thankfully the account still had the flow saved within it (account was just deactivated - not deleted). Once active again, in Power Automate there is a "Save As" option for flows shared with me. So thats what I did. Save As > updated the Survey123 connection to use my admin account and I think I also had to reset all the dynamic content, but at least the original placeholders were still there to reference (just not linking to the source content properly).

Will reply to the Service Account bit below @abureaux's reply.

abureaux

This sounds... wrong. I have 1 connection and have >100 flows attached to it. I refresh the one connection every week.

Also, that account issue isn't a Power Automate problem. I 100% recommend using a service account for creating automations in any environment and also centralizing those automations under that one account rather than have a wild west of everyone and their dog making their own.

It's Monday morning and I've already processed >100 S123 requests. By the end of the week, there will be thousands. The biggest issue I've had this year was on Esri's end with PDFs being broken (no checkboxes). Otherwise, smooth sailing. And if I were to leave, nothing would stop working correctly.

In all, I'm quite confident in the Power Automate set-up.

(@Bud definately not an ideal spot to be in. Hope you can convince them otherwise!)

Bud

"IT reactivated the account, we found the flow and got it running again, but to keep it running I had to change ownership of the Survey to my admin account and then recreated the flow in my PA account too (so her account could be deactivated again)."

Did you have to recreate the flow from scratch, creating each action manually? Or is there a way to export and import the flow?

Doing it manually sounds like it'd be very time consuming and error-prone for complex flows.

Our I.T. department doesn't seem to be interested in creating a central Service account for flows, to handle the scenario where people leave an organization and their PA account gets deactivated. So we're scratching our heads because we suspect it will all go sideways if our non-I.T. PowerAutomate super user ever leaves.

LindsayRaabe_FPCWA

Just been trawling through posts trying to find "best practice" type content. Still not very confident with anything related to Power Automate. We recently had someone depart who had a flow setup with Power Automate and Survey123. The Survey was in her AGOL account (which was still active but disabled) but as soon as her Micrsoft account was disabled by IT post contract finish date, the flow failed. IT reactivated the account, we found the flow and got it running again, but to keep it running I had to change ownership of the Survey to my admin account and then recreated the flow in my PA account too (so her account could be deactivated again).

On top of this, I'm still finding that each flow connecting to Survey123 requires a separate connection - you can't reuse a previous connection (even if it says you can and have) - the flows just don't run.

Bud

Adding my backing to this idea. We've been using Power Automate/Flow to enable email notifications, and it is sooooo frustrating because of how fragile and cumbersome it is. We can't reuse a Survey123 Connection across flows, having to create a new connection for each, and have regular instances of flows failing despite no changes having been made, with new connections being the only way to fix it.
This is on top of having to use a dedicated service account as the send email (which we GIS people aren't allowed to manage meaning we need to get IT involved in any new flows).
A built in email notification with basic ITTT functionality based on values in the survey would be an immense improvement!

Bud

Pasting screenshots no longer works. But you can save them to a file and then drag/drop them in.

https://community.esri.com/t5/community-feedback/pasting-screenshots-in-community-posts-no-longer/m-p/1686209/highlight/true#M6092

abureaux

What mechanism do you use for your timer, such as FME, and how often do you run it?

Power Automate workflows.

and how often do you run it?

Varies by workflow. Anywhere from 1/day to 1/min. Depends on how "important" the workflow is and how much throughput I need.

All the workflows generally start the same though. I was trying to add a few screen caps... but that doesn't seem to be working right now. I'll try again in a bit.

Bud

What mechanism do you use for your timer, such as FME, and how often do you run it?

abureaux

Can I rely on the webhooks to fire 100% of the time?

TL;DR. I don't.

I use Power Automate for all my Esri automations, and at this point I have several hundred automations powering numerous business needs from Health & Safety to field data collection. It is an integral component to our business operation, and we are one of the leaders in our consulting sector. A fancy way of saying I have a zero tolerance policy for "hickups".

Originally, I used the Survey123 connector "When a survey response is submitted". In the last year and a bit, I have completly dropped that connector in favour of an automation that runs on a timer and modifies the feature layer directly. The reason for the change was I found that the Survey123 connector was good, but not perfect. E.g., they would sometimes not detect a response and thus not work. I deal with hundres of submissions per day, so perhapts it is a volume thing. For a large-scale enterprise set-up, I would almost definatly recommend the timer approach for kicking off flows as it allows for retries/error handling. If you are doing things in a small-scale though, I don't see it being a problem.

Using a timer allows you both freedom for design and building in error handling, all while giving you peace of mind that nothing will be missed.

Bud

A comment about the refresh/time out issue from @bcaldwell in Timeout for Power Automate ArcGIS Connector:

Going to chime in for 2025 - still have issues with the ArcGIS Connector timing out. Currently I'm pushing WKT geometry and attributes to AGO when a row is added or updated in a dataverse table. We had a lull in field data over weather, which also meant no updates to the dataverse table, so I'm assuming the connection still has to be jiggled every two weeks, unfortunately. I suppose its time to write a scheduled flow 😄

Bud

A related comment from @abureaux in Power Automate workflow using Survey123 Connector from 2023:

I have used Power Automate to automate S123 for a (newly) multinational company for the last ~2.5 years. I have ~300 automations set up for various purposes. A large number of those automations are rather complex as to support high-level business operations.
I have encountered the odd issue/error that causes unexpected/unexplained failures, but some simple error handling auto-corrects those. The biggest hurdle I've encountered was when Esri releases updates that break things. They typically fix those mistakes with ~24 hours. Definitely the most stressful times...
Overall, I am quite happy with the level of redundancy, security, and reliability. While I haven't done an official up-time calculation, we are definitely way up there since my record of downtimes is almost non-existant this year (beyond my regular EOM maintenance).
They really simplified the automation process for Enterprise this year as well, which is nice.

KhaledHassen

Please let me know if your services that see a delay in webhooks notification. We have been scaling the webhooks infrastructures to handle the load. But will be good if you can share a url of a service that sees a delay in webhooks notification. We would expect notification to be between 1-5 mins.

Bud

AGOL feature service webhook not firing

Improve ArcGIS Online Feature Service webhook performance

Bud

A different contact said this:

I'm guessing (keyword) that the webhook is relatively reliable. I'd be more concerned about setting something up that depended on a connection to the outside world without some kind of client side cache in place (e.g. what happens if an event occurs that would trigger a AGO webhook, there isn't any network connection to fire off that event through? Personally, when building mobile (or any disconnected sort of system), I always like to write new data to a local location and have a background thread that runs which polls the data location and sends any required updates to the server system when a connection is available. The background thread's only job is to constantly try to get data from the local storage to the server and no data is removed from the local storage until the successful transfer to the server is acknowledged. That may be overkill, but I don't like losing data.

Akshay Harshe

@Bud I am not sure what does the contact of yours mean by misfires. Just to be clear ArcGIS Power Automate connectors has nothing to do with webhooks being slow, not triggering or misfires. We are open to investigation if they have reproducible run.

I have seen many of our users use the use case you mentioned successfully with our triggers. You can choose to use the methods that works best for you. Like I said, workflow design is crucial when it comes to Power Automate.

Bud

ArcGIS Architecture Center > Webhooks

Webhooks are generally considered an effective, but not foolproof integration method. As they are loosely coupled to the destination endpoint, there is no guarantee that a message from the source system will reach the destination. Issues like network outages, a failed endpoint, or a badly constructed message body could cause that message to fail.

This means that webhooks are not perfectly reliable, though not significantly different from any other REST API or endpoint which could suffer from the same reliability challenges.

Webhooks require line of sight network connectivity. When an event occurs, webhooks are sent immediately, and if any network access or outage interrupts this request, it can mean that the payload never reaches the final destination. While some systems support automatic retry logic to re-send a webhook payload, this cannot always be relied on, and may result in lost messages in inconsistent network conditions.
Webhooks do not guarantee delivery. While retry intervals and attempts can try to achieve a higher rate of success, webhooks do not guarantee that every event or trigger will result in data reaching the destination system. While this can be acceptable for many workflows, consider whether a post-process to validate data completeness may be required to guarantee that all events were properly processed.

Bud

Thanks, Akshay.

On a side note, a contact had this take on webhooks:

I have used webhooks in the past, but I always used them slightly differently from how they were designed. I just use the webhook to trigger a workflow that uses a query; this way, you pick up things that misfired. I also run the workflow on a schedule to pick up things should it all go bad. I have had IT suddenly block the incoming, ESRI side broke, etc., and users never noticed. I had the workflow logging processed records and what fired. If you watch those, you quickly see that a webhook has broken.
I think they call what I do a tickler rather than a webhook. I just use it as a tickler even though it is designed to send the data in the hook.

Akshay Harshe

@Bud Thanks for your question.

All the triggers related to Features/Attachments created, updated, deleted are server-side triggers. Currently, `when a survey response is submitted` trigger uses client-side approach (which may change in future) that are almost instant. S123 trigger is reliable for the amount of usage they get from all our customers. Yes, it has its shortcomings and issue 5 mentioned above is I think related to having too many fields in the request which Power Automate doesn't like.

In the past, we have had issues with server-side webhooks through ArcGIS Online being slow to trigger. Many of our users have previously complained that they didn't run reliably. Some of the issues issues you posted are associated with that, while some of them were related to outages in the Azure and our connector back-end last year. Others in-fact, were related to the webhooks performance.

That said, we have worked with ArcGIS Online team and they have resolved the performance issues in the recently released ArcGIS Online version 2026.1. This has internally rehauled the architecture of how the webhooks are triggered reducing previous bottlenecks. From my testing, the current server-side webhooks trigger within1-3 minutes. Please let us know if you experience is otherwise.

If this isn't acceptable time frame then there are ways to bypass the webhooks altogether in automation. That would add some overhead creating and maintaining the flows. It may or may not be for everyone.

So, can you rely on webhooks 100% of the time? I would say any technological system isn't flawless and there will be bugs and errors. Just because we have self-driving cars doesn't mean we completely let go of the steering; well at least not yet. I would recommend designing smart flows and think about how you can get notified and handle errors if and when they occur. This can include, Sending an email if the `Fetch updates, changes, deletion action` fails or setting up retries on actions if they fail the first time, etc.

Lastly, we are here to help and improve, so please keep posting your thoughts, questions and comments.

Here is a webhook troubleshooting guide our developer has put together if you wish to narrow down some of the common problems we have seen in the past

https://community.esri.com/t5/arcgis-connectors-for-power-automate-questions/guide-troubleshooting-arcgis-and-arcgis-enterprise/m-p/1634995#M1058

Bud

This isn’t strictly about reliability, but it talks about timing, which seems relevant:

Why is there such a big delay between a trigger and the action?
While some flows can be instant, there are many cases in which there is a delay between a trigger and an action and vice versa. For example, when using the ArcGIS connector in conjunction with a Microsoft SharePoint connector, there is a delay (one to three minutes) when processing information.

https://doc.arcgis.com/en/power-automate/latest/get-started/faqs.htm

A few related posts:

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.