Monthly Archives: July 2020

PowerAutomate Flow does not require change tracking to be enabled for a CDS entity

There was a quick discussion on linkedin yesterday where the post by Jerry Weinstock stating that change tracking must be enabled for the Flows to work was mentioned:

Given that I did not do anything with the Flows 3-4 years ago, and I never had to worry about change tracking recently, I was a bit surprised to hear that. Still, who knows? Maybe I always used Flows with the out-of-the-box entities, after all.

So, just to confirm: change tracking is NOT required for the new CDS (Current Environment) connector. It is required for the Dynamics 365 connector, and, keeping in mind that the original post was dated 2017, that’s exactly what it was about.

It’s easy to test. Where the Flow that’s using CDS (Current Environment) connector trigger runs fine on update of the CDS record:


The other one, which is using Dynamics 365 connector, is complaining:


Can’t help but notice how quickly everything is changing, btw. I keep running into these examples, with my own blog posts as well, where what used to be correct even a couple of years ago is not quite right anymore (or, at least, needs clarifications).

On the one hand, this gives me an almost unlimited source of topics to write about. On the other… Nothing feels quite as fundamental as it used to be.

Well, we can only embrace this rate of changes and go with the Flow!

PowerAutomate Approval entities in CDS

I was playing with the PowerAutomate approvals tonight, and, since I have not used them at all before, I am wondering if CDS is an “add on” for the approvals or if CDS is a pre-requisite?

See, when looking at the link above, it seems I don’t need CDS to work with the approvals:


However, all Approvals-related entities are already available in CDS:


It seems there is not a lot of documentation covering approval entities in CDS, but there is this support article which is interesting in a few ways – first of all, it confirms that approvals data is, in fact, stored in CDS. However, it also makes a point that “the schema is complex, not publicly documented and is subject to change”:

What I was interested in is: can we use CDS approval entities to create a Flow that will start once there is an approval response and what kind of information can we extract from that response in the Flow?

Turned out we can certainly create such a Flow, and, also, we can extract all the information we need.

Well, this post would not be worth much if it were all straightforward, right?

So, of course, there is a gotcha.

In the CDS environment, you will have Microsoft Flow account:


This account, by default, will have only one role:


As soon as you create a PowerAutomate Flow that is triggered on create of new Approval Response in CDS, you will suddenly lose the ability to approve all those approval requests. Even when using a full admin account, you will be getting an error:


This is a weird error, since there is just no way my account would not have CDS permissions. The error message is way more detailed when trying to approve a request through the web portal:


With that ID, I can quickly prove that it’s a permissions error for the “Microsoft Flow” user account:


So, in order to make this work, you will first need to create a security role that gives read access to the “Systme Job” entity and assign it to the Microsoft Flow account:


Why did I call it “Microsoft Flow Approvals”? Well, it’s “Microsoft Flow” account… You can call it “Power Automate Approvals”, thoughSmile

With that, everything starts working – I can continue approving all those approval requests, and, yet, the Flow I had set up to respond to new approval responses is working, too:


This kind of Flow allows for some interesting options. For example:

what if you had multiple approvers for a certain type of approval requests, and what if you wanted to keep sending reminders to only those of the approvers who are not very responsive? It seems PowerAutomate Approvals themselves won’t get you enough flexibility to do that – you will be able to send a reminder, but the best solution I’ve seen so far (unless I misunderstood it), even though it will allow you to send reminders to all approvers in a parallel Flow branch, still won’t be able to differentiate those approvers who actually need to be reminded from those who have already provided their approvals:

Once you start working with the CDS entities, each approval response will have its “Owner” set to the approver. So, if there are two required approvers for an approval, you will only need to send a reminder if there is no approval response owned by that approver for the approval request.

PS. Actually, now I’m thinking creating such a reminder might be a good exercise for the upcoming PowerStorm session on July 16: At least it’s one option among a few I’ve been thinking of so far, though any suggestions you might have are welcome. And don’t forget to register while there are still a few spaces, btwSmile

Lambda operators in Web API

I have never, actually, noticed, there are lambda expressions in Web API.


It seems this part of documentation was updated about a year ago, I just did not know there was this addition. Well, it’s nice it’s all on github now, so I can actually go there and see when something was added. Just in case I wanted to figure out how long I’ve been unaware – from that standpoint, I’ve been certainly hitting the records lately.

Why are lambda expressions worth mentioning?

Those are, really, your “exists” / “not exists” with Web API.

There are two flavors:

  • all: allows you to build a filter that will be applied to all related records, and, if all of them meet the criteria, the query will return data
  • any: same as above in terms of records and relationships, but this time the query will return data if there is at least one related record that meets the condition


So, basically, we start with the main entity, then we add all/any expressions through the relationships, and each of those all/any can have conditions on the related records. More specifically, “any” can be used without conditions, but “all” has to have some conditions:


<ORG_URL>/api/data/v9.1/accounts?$select=name&$filter=contact_customer_accounts/any() and contact_customer_accounts/all(c:c/emailaddress1 ne null)

That’s pretty cool, huh? And we can use this in the Flows with the List Records action when defining the filters.

Anyway, that’s some useful stuff, it seems. And, for the original docs, just have a look here:

2020 release wave 2 teaser

With the release plans out there now, I guess quite a few of us have been browsing through the documentation trying to figure out what is it we’ll be able to do once all those new features become available.

It’s sometimes difficult to gauge what exactly the product team is planning to release just based on those notes in the release plan, so, sometimes, we can only guess. With that in mind, there are a few thigs I’d be looking forward to try.

We seem to be getting reusable code in Canvas Apps


I have at least a few questions about how exactly this is going to work, since our inability to reuse “code” has been a long-standing problem in the Canvas Apps world. Of course this may mean that my “Code Reuse” tool for XrmToolBox will be short-lived, but that’s just for the better. As much as I recognize the importance of XrmToolBox for the community, I would very much prefer all that functionality to be provided by the platform itself. If we were able to, essentially, start creating reusable “functions”… oh, that would be awesome, and I’m hoping that’s exactly what it is.


Canvas app will surface themselves in the model driven apps in the form of custom pages


This goes really well with my “canvas apps will take it over” conspiracy theory. It seems to be yet another step in that direction!

This one will probably make a headline in the CRM Chart Guy (aka Ulrik Carlsson) blog


You might be using Power BI these days, but there are still out of the box dashboards. I believe this is all about closing the gaps in preparation for the following item, which is

The decommissioning of the classic web client


Like it or not, the days of the web client are counted. Take the screenshots while you can – classic web client has served us well over these years, but it’s, finally, time to let go.

On the PowerAutomate side, there is a lot of emphasis on the RPA. Just look at the list of features listed in that category, compare that with the other two, and you’ll see why I’m saying this


As far as Power Virtual Agents go, think I’d like to try this one


Anyway, if this has sparked your interest, there are a lot more features listed in the 2020 wave 2 release plan. So, instead of me trying to summarize them here, just have a look for yourself:

I’m sure everyone will find something to look forward there – pretty much every area in Power Platform will get some features and enhancements as part of this release.

Working with regardingobjectid type in PowerAutomate Flows

A colleague asked me a question earlier today (I can probably use this theme for half of the posts here… for that matter, do you have a good question? Feel free to askSmile ):

“why is this Flow condition on regardingobjectid type not working?”

And the condition looked more or less like this:


(It’s truncated on the screenshot, but it’s “Regarding(Type)” in there)

At first, I was like “no big deal, there is something wrong with the Flow”. So, I tried to create a manual Flow which would pick a task and would have the same condition there. The same condition in this Flow actually worked fine!

And, of course, I said “see… it’s definitely something with the Flow”. But I kept thinking to myself it’s unlikely this particular colleague would make a rookie mistake somewhere, so… I tried a Flow that triggers on create of a Task. And you know what?

The same condition in this new Flow did not work!

Let’s dig into it a little more, then?

Here is the Flow that worked:




The reason I had “Compose 4” step is that I wanted to see the json payload. Here is what I saw:


There is this particular line in the payload, which actually makes the difference between my two Flows:

“_regardingobjectid_value@Microsoft.Dynamics.CRM.lookuplogicalname”: “account”

The other Flow (which is triggered when a new task is created) did not have all those nicely expanded properties:


See how the only thing we really know about _regardingobjectid_value is the id? Which is exactly why my condition works in the Flow when I’m selecting records from CDS in a separate action, and it does not work when the Flow is just responding to a trigger.

Since here is how those Flows are trying to access regardingobjectid type:


That information is just not available in one of the Flows (the one which is triggered when a new task is created).

Well, now that we know what’s happening, how do we handle this?

I see a couple of options how to make this work in the Flow that is triggered by a new task:

a) We can use the following expression:


That produces the following output:


Notice that it’s “accountS”, not “account”. This will work for the condition, but it’s sort of inconsistent with the conditions we need to use for the tasks which are queried from CDS within the flow. Those actions won’t have regardingobjectid_type in the output (I checked, but I would encourage you to double-check).

b) We can add “Get Record” action right after the initial trigger, and we can work with the output of that action instead

Essentially, this turns it into a Flow which works with the records queried from CDS rather than with the records which came in through the trigger, and it just works as it should:


PS. In retrospect, my original thought proved to be correct, btw. It was something with the Flow, just it was not the way I thought it would beSmile