of the
Today’s tip is indirectly from Alex Shlega. Alex is very thorough in his writing so I was a bit surprised that his answer to running a synchronous flow from a webhook was a ‘no’. The reason cited was that
CDS “execution pipeline” won’t wait for the Flow completion.
Well, it will indeed not, but only because we need tell it that we are going to return something. The moment you add a Response action, the webhook becomes synchronous.
There is a catch, of course. If you update the same record in your flow, you will enter a loop. And you will enter it from a separate process whilst blocking your original request. It means you can’t break that loop if you update the same record. The original update waits for the flow to complete but the flow can’t complete because it waits for the original update to release the record so that the flow can update it. Which is a classic deadlock.
In short, if you update the same record then no matter what you do, the original update will fail.
However, if you update does not touch the same record or entity then it will work. To illustrate, I added a calculated field to the account entity that displays main telephone of the primary contact. Registered the flow as a webhook and included pre-image with the primarycontactid:
Inside the flow I update the primary contact record with the +1 <company main number>:
The end result? Primary contact record is updated very much synchronously:
Is synchronous flow possible? Yes, it is. Is a good idea? With the deadlock and infinite loop on the cards, it is probably not.
Cover photo: Waiting for Godot, text by Samuel Beckett, staging by Otomar Krejca. Avignon Festival, 1978. Rufus (Estragon) and Georges Wilson (Vladimir) / photographs by Fernand Michaud / CC0
Awesome! A couple of folks suggested adding the response code, but the Flow kept failing, and I did not think it through to figure out it might be the deadlock. It kind of makes it less useful (as a synchronous response), though, since making changes to the same record is 80% of my usage scenarios for synchronous plugins/real-time workflows.
Noticed something else, too. If the web hook registration is updated to run in pre-validation, it still fails when trying to update the original record. Pre-validation is supposed to run before the transaction(unless it’s somehow different for webhooks), so this might not be the case of SQL deadlock, though, if not that, I am not sure what it is then. The webhook, in my case, is filtered by attribute, and I’m not updating the same attribute from the Flow, so it should not be a “flow invocation” loop either.
Yes, I’ve tried prefiltering too. I think it’s still a deadlock just on the interprocess comms instead of the database. The other possibility is that skipping the flow does not actually return 2xx code so that the caller keeps waiting and times out after 60 seconds.
It’s certainly not very scaleable and should be used with extreme caution. As I explained elsewhere, imagine a dev writing a plugin on contact update and decide to update linked account. They wouldn’t think twice about the flow and that would cause some serious troubleshooting grief.
Great Idea!
Using right now!