Monthly Archives: June 2020

Spooky scary licensing caught up with me again

Not without some help, but, it seems, I’ve just uncovered a skeleton in my closet. Which turned out to be this old blog post I wrote back in September 2019:


Now, I stand corrected TWICE in just one day (just for the reference: That’s a little unusual feeling, but, well, the truth has to come out, so… What I wrote back then is incorrect. To my excuse, it was correct then based on what I knew then, but it has become incorrect some time between then and now. Which is precisely why licensing can be just as spooky and scary as those skeletons.


You are probably aware of the various API limits in CDS – if not, have a look at the following documentation page:

If you are aware, but if you did not think twice of the batch requests, have a look there anyway.

There is lots of stuff there, but the reason I’m writing this post is that there is this note which was added some time in December 2019:

 Entitlement limits … requests… include operations performed by… $batch (ExecuteMultiple)


To reiterate: for the entitlement limits, those individual requests within batch will still be counted separately, so, for example, this may have implications for the data migration, data integration, etc.

Just keep that in mind. And, with that said, let’s keep moving on.

How big can an IFrame be on the model-driven form, and how to make it even bigger?

Did you ever try to put a really big IFrame on the model-driven form? If you did, and totally irrespective of why you would do such a bizarre thing, you might have seen this message:


Those 40 rows, whatever they mean in pixels, is the maximum you can get if you go with a regular web resource/iframe.

However, if you create an IFrame PCF control, you can make that IFrame as big as you want. In the example below, I can easily get to 3000px height with the PCF control:



Whereas for a “native iframe” control all I can get is 1960px:


So, why would it matter? Well, there might be a long data entry form you wanted to display there. That seems to be my scenario. But, even if that’s not a very common scenario, it’s just an interesting fact that PCF controls are not limited by those 40 rows – be it an iframe, a long text area, a huge grid control, etc.

Have fun!









  • A 200 (OK) status code.
  • The content type must be text/plain.
  • The body must include the validation token provided by Microsoft Graph





Which means you will need to create a Flow first.

Here is how my Flow looks like:






For the loop, here is what I did:






This is what “List records” action will be doing:








And what’s left is to actually set up Graph notification.




There are a few things to keep in mind there.








Hope this helps!

Can we call a PowerAutomate Flow synchronously on create/update of a record?

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:

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:

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:

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 ( Unless it’s not the case for the web hooks?

Canvas apps vs Model-Driven apps (a follow up)

Here is a really quick question before you continue reading. When looking at the image below, can you see what’s wrong there?


Of course the answer is – it’s a Canvas App trying to pretend it’s a model-driven app:


That’s a little experiment I wanted to try, and, quite honestly, as entertaining as it was, it ended up being quite educating, too.

I mostly work with model-driven apps, so I know that Canvas can give us better control of the UI, and they can also connect to different data sources. Although, the latter (usually) does not matter too much in my world since, again, I mostly work with model-driven, and that assumes CDS. However, just recently I came up with a post ( where I sort of entertained the idea that Canvas App might be taking over in the long term.

Of course that brought up the concept of app types convergence, which also makes sense. There are different ways this can play out eventually, but that all lead me to try the experiment above, which, in turn, lead me to a couple of realizations.

First of all, I realized that I used to underestimate the fact that CDS is “just another datasource” for the Canvas Apps. I used to think Canvas Apps are giving much better control over the UI, and that’s correct. However,  when writing that app above, I might as well be using a Sharepoint connector to store data in Sharepoint while still presenting it in the replica of the UCI interface. In other words, Canvas Apps don’t care what the data source is.

I know it’s obvious. When it matters, though, is when somebody starts comparing those two app types. Essentially, when Canvas and Model-Driven are compared exclusively in the CDS world, model-driven will, likely, win. But, as soon as another data source shows up on the horizon, there is nothing model-driven apps can really offer.

I have also realized that I used to overestimate Canvas Apps UI capabilities. Right now, at least, there are limitations all around(no code reuse, no ability to use nested components, no ability to have really granular control of the HTML events/styles, etc). This is understandable, since implementing those features in the low-code framework might be challenging, and not only for the technical reasons, but, also, because this might ruin the whole concept of low-code. I knew those limitations were there, but, I guess, it’s hard to realize how strong the wall is till you hit it.

And it’s probably the case of the devil being in the details – for example, I can have a button, and I can have an icon, and I can put that icon on top of the button. However, that suddenly stops the button from receiving “mouse over” event when the cursor is moving over the icon. And that messes up the colors (HoverFill vs Fill).

Still, does this change anything for the original post? Not really. It just proves that, at the moment, there is no winner yet, so we’ll just have to wait and see where this goes.

Free non-production regex connector for PowerAutomate Flows

In a few of my previous posts, I used a custom connector which had a “regex” action implemented in it. In case that’s something you might try using in your flows as well, a non-production version (no up-time guarantee, no guarantee at all whatsoever. Feel free to use it, but you can’t hold me responsible) is now available as a CDS solution.

You just need to download the solution file from github:

Once you’ve installed the connector, you should be able to use ItAintBoring Regex action in your flows:


So, when given the following phone # pattern:


And the following value:


It will produce this result:




The source code for is available here:

Please note that this connector is using a php version of the API, and, basically, it’s utilizing preg_match function:

It will either return null if there is no match, or it will return a value that corresponds to the first captured parenthesized subpattern (so, basically, whatever matches the expression started with the leftmost parenthesis).

CDS Post Images and CDS Pre Images in PowerAutomate Flows

Full disclaimer… this post was triggered by what a fellow MVP, Olena Grischenko, wrote earlier today: 

I am all for plugins, I actually write them every daySmile But, then, should not there be some way to work with pre/post images in PowerAutomate? Without code?

And there is one, although “no code” solutions are not, always, the easiest:


Basically, we can set up CDS to send pre/post/target data to a queue in Azure Service Bus. It’s not a complicated process, you just need to follow the steps described here:

Just make sure to use json message format when setting up the integration:


Once that is done, you can start adding SDK steps. And, for those SDK steps, you can start adding pre/post images:


Let’s say that’s been done.

The next step would be creating a flow. PowerAutomate has a connector for Azure Service Bus:

So, set up the trigger:


The remaining part is all about parsing that json from the message queue. Unfortunately, there is no “native” regex capability in Flows, though there are a few third-party connectors there. I did not try those, pretty sure they would work, but this is where “no code” is not the same as “no fees”Smile

Instead, I just opted to tweak the regex custom connector which I blogged about some time ago:

Here is the code I used for the regex action this time:


Now, once there is a regex connector, I just need to add a couple of action to extract “name” field from the pre image:


And, also, to extract it from the post image:


This is where you may have to look at the json and figure out how to write that regex expression (might need to test it in the regex tester).

Once that is done, I can access both pre-image and post-image values of the “name” attribute. In my case, I simply sent an email to myself:


And, once the email came in, both value are there:


What are the caveats?

  • We need to create azure service bus queue
  • We can’t rely on the capabilities of the CDS connector. Although, plugin registration tool is a powerful tool, so this is really a problem for the next step
  • Since we do need to figure out how to parse that json

But, in either case, except for the regex connector, this is a no-code solution to the problem. Might actually be possible to just use a bunch of “substring” and “indexof” function calls to do the same, but it’s probably easier to just set up that custom regex connector (or to subscribe to one of those which are already available in Power Automate)

In the battle of Canvas vs Model-Driven, is there a winner?

To start with, why do I even call it a battle? Isn’t it supposed to be a peaceful coexistence where each type of power apps can contribute where the other type is lacking in functionality?

In theory, yes. In practice, it seems things may spin out of control in the extreme cases. Imagine there is a relatively complex data model which would normally justify model-driven approach, and, yet, there is a really strong push towards custom UI. Which would, in turn, normally justify utilizing a canvas app. Would you choose a model-driven app, or would you choose a Canvas App?


I guess Canvas Apps are non the left side here…

Or, possibly, on the right…



Actually, I’m not going to even try to answer that question, since there can be no perfect answer, it seems. However, while thinking about it, I got a strange idea.

Would it be so impossible if the ultimate goal of the product team working on the Canvas App technology were to eventually replace model-driven apps with Canvas Apps?

Nonsense, you’d say? Maybe, but… Consider:

  • Canvas Apps have come a long way since they were first introduced a few years ago, whereas model-driven applications, at least the way I see it(forgive me Microsoft), got a lot of face-lifting efforts put into them, but, other than that, they are still the same old Dynamics CRM
  • Component Framework is now available for both types of apps
  • Most of what is doable with web resources in model-driven apps can also be done on the canvas apps side
  • Canvas Apps support various data sources, whereas model-driven can only work with CDS
  • Canvas Apps support user interface customizations which are beyond the reach of model-driven apps
  • Canvas Apps, in the form of embedded apps, are already making their way into the model-driven world, but I am not sure the opposite is true


Is there anything a Canvas App can’t do(with the proper application of development efforts) that a model-driven application can? Interestingly, I would not even think to ask that question a few years ago (“whaaat? Are those, really, apps?”)

Of course, and that seems to be the main factor that’s still keeping model-driven apps alive, it would take a lot of time to create a Canvas App from scratch that would provide the same level of functionality that a model-driven app can deliver in just a few minutes.

So, what’s going to happen if and when Canvas Apps product team closes that gap and adds yet missing components to the Canvas Apps? What if there were a command bar control? Left-hand navigation control? A quick find control? They might not show up tomorrow, they might not show up a few months from now… but, looking at where the Canvas Apps are now, after just a few years of being around, would it really be that surprising if this happens in a few years?



TDS endpoint for custom development and data integrations?


There are other usage scenarios which seem to be very enticing.

Using it for data reporting would be one option:

There are at least a couple of others, though.





What are the benefits?





2. Data migrations with SSIS



You just need to create an ADO connection:


And use ado data source after that:






Adding basic self-service to the custom portal



Self-Service Tickets


Again, you will find the source code in this repo:


You can also try it “live” here:

A few things might be worth mentioning.



2. .NET Core vs .NET Framework


There is a .NET Framework version:

And there is a .NET Core version:



3. Security


