Monthly Archives: May 2021

How to continue flow execution after an error

When handling errors in the Flows, we can add parallel branches so one of those would run on success, the other one would run on error.

However, in the example below, there is a Flow with two parallel branches configured that way, and, even though “On Error” branch is there, the Flow would only execute that branch, and it would not continue from there:


What if I wanted to handle an error, but, instead of having the flow terminated, I’d need it to continue from there? The specific scenario I came across recently is having to loop through a bunch of Dataverse records, so that, for each record, there would be actions in the loop. Some of those might fail, and, if they do, I’d need to log an error. However, that should not prevent the flow from processing all other records – it should simply continue to the next record.

Turns out this is doable, but it needs to be done differently:


If you wanted to handle an error, you could create two parallel actions – one of them would run “on error”, another one would run no matter what (see above). In the one which would run when the previous action had failed, you could, then, do error handling.

In the one that would run “no matter what”, you basically would not do anything at all – just need some action there, though, so I used “Compose” in the example above.

This would now allow the Flow to proceed to the next step even when an error happens, and it’ll look like this:


I am not sure what kind of logic apps/power automate rules are at play here, but, it seems, this way we can implement error handling while still allowing the flow to continue after an error.

PS. I might combine this with the “scope” if I wanted to add error handling not just for a single action, but for the whole scope.

New solution designer is moving backwards – and that’s great! We can see hidden elements on the forms now!

It’s been a while since “treeview” experience had been added in the preview portal:

Now we can also see “hidden” elements in the form designer! Classic designer had some nice stuff, after all, and now those features are making their way back into the new designer.

There is “created by” on the form below, but it’s hidden:


I can now flip “Show Hidden” to “On”, and there we go – the field becomes visible in the designer:


PS. Make sure you are using “preview” version of the designer if you wanted to try it for yourself (so, just add “preview” to the url:

I just barely passed MB-230: Microsoft Dynamics 365 Customer Service

And I do mean barely. As in, I had to get 700 out of 1000 to pass, and I think I got 738.

Under the normal circumstances, I probably wouldn’t even try taking that exam, but there was a reason I wanted to do it, and quickly, so there we go… a Power Platform consultant decides to take a D365 Customer Service “functional” exam and it ends up being almost a failure.

But, of course, in the end what matters is that I have passed. Combined with PL-200 that now makes me a “Microsoft Certified: Dynamics 365 Customer Service Functional Consultant Associate”, which is exactly what the goal was.

Still, I was impressed with what I’ve seen in D365 while getting ready for the exam, so wanted to share those impressions while they are fresh a little more.

Although, I am not planning to talk about D365 functionality below. At least not for the sake of explaining how to configure things. For that, you can download skills outline from the exam home page and look up each of the topics in Google. You will find Microsoft docs are surprisingly comprehensive these days – almost everything is covered in great details. Combined with the various learning paths and a trial environment, that should give you enough material to prepare.

I’ll just emphasize that this is really a “functional consultant” exam – it’s all about how to do certain things in the specific first-party application. So, you have to learn the functionality, and there is a lot to learn.

Which, to be honest, makes perfect sense for a solution architect and, to some extent, for a developer, too. Since, if you don’t know what’s there and how it works, you won’t be able to build your solutions on top of what’s there – you’ll have to build from scratch.

Anyways, while studying for this exam, I could not help but notice how a lot of the functionality could probably be implemented in our custom model-driven applications. And, yet, some of that might not be doable.

Is it possible that “first party” apps have  certain advantages over the apps we can develop? It would kind of make sense, since internal dev teams have god-like powers which might allow them to bend the rules sometimes, and we, mortals, just have to follow those rulesSmile

So, let’s look at some of those things from the “architecture/development” perspective.

I’ve already written about how Omnichannel is using form-specific links in the left-hand navigation panel, but that was just one of a few.

Here is another one: Omnichannel installation experience.

In the PowerPlatform admin portal, we can start provisioning an Omnichannel application this way:


That will open up a dedicated provisioning web page – the whole provisioning process is described here, but here is a screenshot to save you a trip to that link:


You can see how a web page above is loaded from a completely different url, and we could do the same in our apps. Creating a custom web app for the installation – why not? It might not be worth the efforts for smaller apps, and it might not be feasible without a dev team, but, if you are really working on something big, that’s not a bad choice.

In the context of the recent discussions about what pro developers can do in Power Platform, that’s one area where a pro-dev on the project could help quite a bit.

But, of course, this is more an ISV thing, since, if this were an internal application, we could easily get away with a manual one-time installation.

Other than developing an “application portal” to support this kind of installation experiences, there is, also, another options, and that’s package deployer, since it allows us to create “custom code that can run during or after the package is deployed to Dataverse environment” (which is another way to say “you can do whatever you want – add data, perform configuration tasks, etc… all from within your code”):

There is a corresponding “Deploy Package” task in the Power App build tools for Azure devops:

However, you may have noticed that Ominchannel takes it a little further – somehow, we have access to the “Manage” command which brings us to the deployment page. Not sure how that is done and whether ISV-s can, actually, add their apps to the Dynamics 365 apps “folder” in the admin portal (yet to customize that popup menu). Here is what I found in the docs, but I am not sure what it means and if that helps:


Having said all that, let’s look at something else. How is Unified Routing implemented?

I’d think there would be a set of plugins etc, and I am pretty sure there is, but here is something unusual:


In the default solution, there is a thing called “Account routing hub”, and it has “Master Entity Routing Configuration” type. I tried editing that one, and ended up right in the customer service hub:


So what is it, exactly? I am not sure – guess we’ll be able to use those things, too, but we are not there yet. Although, there seem to be a plugin registered on the master entity routing configuration:


So… it actually seems this is very similar to the environment variables. Just like we have environment variables in the solutions now, and those are, more or less, “data”, it seems there is other data that can be added to the solutions (even if we can’t use that kind of functionality yet).

Could we do the same just with the plugins? Probably. That, again, would be a nice piece of work for a pro-dev on the project, but, of course, since it has already been implemented in the first-party app, why would we try re-inventing the wheel (well, except that there are licensing fees, of course).

But that’s enough of reverse-engineering for one post – I’ll get back to this later. It seems I need to look at the unified routing functionality a little more first (and, possibly, write up another post), since, for some reason, it’s still not working in my trial instance 🤔

Model-driven app configuration entity – the most unusual approach I’ve ever seen, but it works

I was looking at the Omnichannel lately, and , then, I realized something that might be worth sharing.

You know how we would often create a configuration entity in our model-driven apps? Omnichannel is doing just that, but it’s taking it one step further. It provides multiple forms for the configuration entity so that each of the forms is exposing a subset of configuration settings, and, then, it adds links to the configuration record… for a specific form… to the left-hand navigation.

I mapped some of those on the screenshot below:


But, in general, there is just a bunch of forms:


Somehow, I never thought of doing it this way, but it actually does make sense – what we end up with is a very smooth user experience.

So, in case you wanted to do the same in your applications, here is how it’s done in the Omnichannel app:


You just need to use a url that would have all the right parameters, so here is an example FYI: