It seems like a no-brainer question with a simple “no” answer; however, there was something that came up on Linkedin while discussing my other post about using CDS pre/post images with the Flow:
https://www.itaintboring.com/dynamics-crm/cds-post-images-and-cds-pre-images-in-powerautomate-flows/
What if, instead of using the service bus, we tried using “web hook” option in the Plugin Registration Tool? It does support synchronous execution, after all:
The url below will provide all the details on how to use that option, so I won’t be repeating the steps here:
https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/register-web-hook
Instead, I’ll jump right to the part where it did not work out the way I hoped it would with the Flows.
I did not have any problems registering a synchronous step in the pre/post operation:
And the Flow itself is relatively straightforward:
The flow will get the request,it will find record guid in the incoming json payload, and it will use that guid to update account phone #.
However, as it turned out, even though the Flow will be called synchronously, CDS “execution pipeline” won’t wait for the Flow completion. So, even though there were a few occurrences when I could see updated phone # right away while testing, most of the times I had to use “refresh” to see the change:
This makes sense after all, since it may take a while for the Flow to finish (not even talking about possible “delay” actions in the Flow), so, it seems, it’s only the initial trigger that will be called synchronously. The rest of the flow will still run a-synchronously from the execution pipeline standpoint.
Long story short… this is definitely yet another option for passing pre/post images to the Flow, but it does not seem to help with the synchronous execution. Yet it’s probably not as scalable as the service bus. Although, unlike with the service bus approach, there are less steps involved here, so this may get the job done a little faster.
Update (as of June 30): this post attracted the likes of George Doubinski (see comments below), so I stand corrected:) See this: https://www.itaintboring.com/dynamics-crm/can-we-call-a-microsoft-flow-synchronously-on-createupdate-of-a-record/
Or, well, I kind of stand corrected. By the way, also wanted to give credit to Shidin Harridas who was likely the first to suggest using the response action.
It seems the question posted in the subject can have different answers depending on what we need that synchronous flow to do.
- We can call the Flow synchronously
- If there is no response action, the web hook won’t wait for the Flow completion, so your CDS operation may complete before the Flow has completed
- If there is a response action, and if your Flow tries to update the same record BEFORE getting to the response action, then the whole process will fail
The last scenario represents about 80% of my use cases for the synchronous plugins/real-time workflows, so the answer to the question might still be “no” with caveats.
So… why does the Flow fail in this scenario? It sounds reasonable there is some kind of deadlock, but it can’t be a database transaction deadlock, since the same Flow also fails when the webhook registration has been updated to run in “Pre Validation”, which is supposed to run before the transaction starts (https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/event-framework) Unless it’s not the case for the web hooks?
There’s a longstanding silent user requirement for “Synchronous” operations, which is “Refresh the page when the operation is done. Nobody wants to manually hit the refresh button.” I think currently the only way to achieve “Truly Synchronous” is by using the traditional xmlhttprequest call (most of the time which isn’t even synchronous.）and then refreshing the form upon success.
I haven’t tried passing pre-images yet. But on that note, what happens if we put an OnChange client side event to call the web hook, to call the Flow (which will then pass back a success message), and then refresh the page if successful? … Personally I’m not creative enough to conjure up a scenario where we require such functionality…
Which brings us back to another related argument, “Why are we still using the Plugin Registration Tool/JScript/JSON” – I thought PowerApps was for the citizen developer??? #WeWillAlwaysNeedDevelopers
Keep up the great work Alex!!! I’ve been lurking through your pages for quite some time! I appreciate your relentless pursuit to answer the timeless question： “Can it do this? Probably not… but let’s try it anyways.”
Hi Steve, I tend to do most of the synchronous stuff in the plugins. When the page comes back (after save), it does show updated values. Although, this does not work that well for the subgrids (since a plugin on the child record might recalculate some kind of “balance” field on the parent, and the user would still need to hit refresh to see the change). Although, you can use javascript to automatically refresh the form whenever the subgrid is reloaded (that’s a little tricky process, but I wrote a post a few months ago:) )
PowerApps are not for the citizen developers only (plugins are part of power apps). PowerAutomate… possibly… we are just trying to use plugin registration tool in the no-code way to integrate with PowerAutomate (strange as it sounds:) ) To be honest, digging into that json and writing up a regex is not exactly what a citizen developer would be happy to do either way, but, as you wrote, “let’s try it anyways”
Have you tried adding a return response action to your flow?
Alex,
Jonas is correct. If you add a response action to your flow, your flow will become very much synchronous. I had a draft on that in the making for quite some time (was not sure it’s a good idea at all). Well… it is possible but it is NOT a good idea 🙂
https://crmtipoftheday.com/1372
Cheers
George
Hi folks, thanks for correction. – I’ve updated the post. George, not sure if this is a database deadlock or if it’s something else (see my note about pre-validation in the updated part, closer to the end). It does not change the outcome (“can’t update the same record from the flow called through a sync webhook”), but I’m wondering what the explanation might be.