Monthly Archives: March 2019

Using different connectors with Dynamics CE instances when creating a Flow


There are at least 3 different connectors we can use with Dynamics CE instances when creating a Flow:

  • CDS Connector
  • Dynamics 365 Connector
  • Http Connector

They are not identical, though, and, from what I have gathered so far, we may need to keep a few things in mind when choosing between the 3:

1. When using a CDS connector, make sure your environment has been upgraded

Otherwise, you won’t be able to see your Dynamics CE database from that environment. For example, here is what showed up when I tried creating a flow in the old Default environment which was never upgraded:


And here is what shows up when I’m working with a flow in my Dynamics CE environment:



2. There are rumors that Microsoft has stopped working on the Dynamics 365 Connector

That said, most of the Dynamics 365 connector functionality seems to be available in the CDS connector. Although, there is no “Create or Update” trigger in the CDS connector, and it’s not unusual when we need the same processing to happen in response to either of those events.

If you are using a CDS connector, you may, then, consider starting to use nested flows:

Which would, basically, look like this:


And yes, personally I think that’s quite a complication for somebody used to the native Dynamics workflows. Which is beyond the point, though, since those are different “technologies”.

However, unlike Dynamics connector, CDS connector has “Current” environment option which is why it can be packaged into solutions. You move it to another environment, and it’s still “Current”, so it just works.

3. HttpConnector is a low-level approach, and, just like any other low-level approach, it’s more complicated to implement, but, of course, it gives you most of the control

Mostly, it seems, we’ll be dealing with these two problems:

  • There is no seamless authentication – here is how you can try working around it:
  • Forming the requests and parsing the responses – both CDS and Dynamics connectors have a rather good idea of what the environment looks like (entities, types, etc). Http Connector, on the other hand, will make no assumptions at all, so you’ll need to know the entity names, you’ll need to know how to write Web API queries, etc.


But, in return, you’ll be able to do everything(?) that can possibly be done with Web API

Updated Advanced condition builder and the importance of the social media

You would think those two things in the subject line don’t have much in common, but I just had a eureka moment, which, I believe, had a lot to do with the following three facts:

  • I am very new to Flow
  • There are things in Flow which are very new to Flow as well
  • And there are people which are exploring all those new things and letting us know of their findings on the social media

Imagine.. I am looking at how to create advanced conditions in Flow so I can do some filtering when an update/create (Dynamics) trigger kicks in, and there is this great video by Elaiza Benitez where she explains those things for the newbies like me:

Great, eh?

Well, of course, except that there is no advanced mode anymore:


So I am rewinding her video to see if I missed anything, and it just so happens that Andrew Ly makes a post on Linkedin where he is praising updated condition builder, and I see it in my LinkdeIn feed just when I am trying to figure it all out:


This is where it hits me. Aha.. Maybe some things have changed?!

So, I am hoping you know by now that there were some changes and they are described here:

In my particular scenario, turned out it really was not that difficult to create a condition I was looking for – I just had to use pretty much the same expression that you’d see in the video above to convert my original field value to 1 or 0 depending on whether that value was empty or not:


if(empty(triggerBody()?[‘_parentcustomerid_value’]), 1, 0)

And, then, I used computed value in a simple “equals to” condition:


Simple indeed, but I am still thinking of the mysterious events of the last hour or so which involved:

  • A youtube video by Elaiza Benitez
  • A linkedin post by Andrew Ly
  • A blog post by Stephen Secilliano

All of which took me from “how the hell am I going to do this” to “it was not that bad at all”.

PowerApps / Dynamics Application designer: don’t just open the sitemap. Open the application, then the sitemap


Remember the old days when all developers (and not only developers) had to also develop an habit of using CTRL+S to save their changes so not to lose them?

There is a bit of that in the PowerApps / Dynamics Application designer right now. Depending on how you add entities to the sitemap in your application, you may or may not get them added to the application. You may also have to remember to hit the “Save” button.

1. When adding an entity to the site map from within the model-driven app, you’ll see that entity added to the application as well

Here is a new app:


I’ve opened the sitemap editor and added Account entity to the sitemap:


Saved and closed the sitemap – notice how account entity has been added to the app, too. I still have to hit save/publish there, but the entity has been added already (not sure how comes “Save” is required at that point, but it is. Even though I can close the app at this point without saving, then open it.. then hit “Save”):


2. Let’s add another entity, but let’s try opening the sitemap directly from the solution this time (not from the application designer as we did above)


Just added Opportunities to the sitemap:


Hit “Save and close”, then opened my application from the solution:


There is still only one entity (account) in the application:


And, if I clicked Site Map to have a look at the sitemap, I would see “Opportunities” and “Accounts” in the sitemap.

Why does it matter?

What you have in the sitemap is only one part of the puzzle when working with the unified interface. There are other pieces which are affected by whether an entity has been added to the app or not. Two important ones I’ve noticed so far are:

  • Unless the entity is added to the app, you can’t add entity other components. So, for example, quick create for that entity won’t work in the unified interface since you would not have quick create form added to the application
  • You won’t be able to create activities regarding such entities in the Unified Interface. Only those entities which have been added to the app will be available for selection. Although, you’ll still be able to add a task, for example, directly to such entity (when you open the entity through the sitemap navigation). Problem is, if you create a task outside of the entity screen, you won’t be able to link it to an entity that’s not in the app


So you really have two options: never open sitemap designer directly from the solution – always do it from the app. Or remember to add your entities to the app every time you add them to the corresponding sitemap.

Wrapping my head around the licensing for Dynamics / PowerApps


There have been a number of really good posts on the licensing so far, but, I think, the main problem for me used to be that I just could not consume all that information till I left the familiar space of the On-Premise implementations and started working in the online environment.

So, in this post, I’m just going to emphasize a few things about licensing that seemed important to me.

1. What is the difference between a CDS instance and a Customer Engagement instance?

Really they are both CDS, but there are different actions you can take on them:

Also, Customer Engagement instances will have those extra solutions which, I believe, you can’t just get added to the regular CDS instances.

I would say that any CE instance is still a CDS instance, but the opposite is not true.

2. What is the difference between a model-driven app and Dynamics CE?

“Dynamics” is nothing but a set of so-called first-party model-driven applications now. Basically, those are model-driven applications built by Microsoft on top of the Power Platform.

In this context, the concept of restricted entities starts making sense – there are certain entities introduced through those first-party applications which Microsoft wants to license through Dynamics plans rather than through Power Apps plans:

It’s as if you created a model-driven app, allowed others to install it, but still wanted to collect licensing fees from somebody willing to use that app in their environments. You’d create a license plan etc.

3. How do you decide which license your users need?

Price. is the obvious factor here. And a PowerApps P2 license would cost you about one third of the Customer Engagement licence.

However, depending on the license assigned to them your users will have different rights.

The diagram below is copied directly from the Dynamics 365 licensing guide:


And there is, also, Power Apps pricing which suggests that, as soon as you have a PowerApps user and you want that user to access a model-driven app (or as soon as you want that user to access any entities relying on the plugins and/or real-time workflows), you need Power Apps P2 plan:


Keep in mind that Power Apps licensing is possible in either type of CDS (“regular” or “customer engagement”). Full Dynamics licensing is only possible in the “customer engagement” CDS where you have those Dynamics applications.

Here is the list of so-called “complex” entities (out of the box entities which require a P2 plan):

Word of caution: apparently, your license requirements may change as you keep developing different solutions. A P1 user working with the Canvas Apps only might suddenly require a P2 license if a plugin gets added by a developer.

4. Can you create custom entities that replicate restricted entities?

Again, looking at he licensing guide:


So yes, now you can.

BUT it does not apply to the Team Member licenses. Although, it’s not so much about replicating the entities – it’s more about the fact that Team Member licenses are given in the context of the main application scenario (Sales, Customer Service, etc), and you are not allowed to use custom entities which are changing the core purpose of the specified Team Members scenario:


Apparently, if you create a custom Case entity, you will be changing the core purpose.

5. So, just to confirm, how would a pure CDS model-driven app look like?

Actually, if you are a seasoned Dynamics user, that model-driven app would look very familiar:


As a system customizer, you will also have access to the solutions, solution designer, etc. Basically, you’ll feel pretty much at home:


6. And what are the gotchas?

Some of the features which are outside of the “restricted entities” don’t seem to be available in the regular CDS instances yet. For example, that applies to the SharePoint integration and to the Outlook App.

However.. based on the diagram above it seems to be possible to add a P2-licenses user to a CE instance, and such a user will get access to those features.

PS. If you are in the mood for more reading, have a look at these two posts:

Demystifying Dynamics 365 & Power Platform Licensing by Jukka Niiranen

Comparison of Dynamics 365 and Model-Driven PowerApp features by Hamish Sheild

Enabling April update preview in the powerplatform admin center

Even if it’s only for myself, I just have to write it down so it sticks. Whenever I want to enable April preview in the environment, I need to go to the Power Platform admin center, and, from there, I need to click the environment link:


It seems to be the only way to open “environment details” screen which is where I need to be to enable the updates.

Why that “details” link does not show anywhere (neither in the drop down menu, nor in the command bar) is a bit of a mystery, but, somehow, it always takes me at least a few minutes to recall what I need to do on that screen.

The importance of not messing with unmanaged customizations when you have agreed to use managed solutions


image You may have managed to put in an unmanaged change in production where you have agreed to use managed solutions only, and it may look like you are doing fine, nobody noticed.. So it’s all good until, suddenly, something starts going wrong!


Here is one scenario that does not seem to work well when you start mixing managed and unmanaged customizations.

Let’s say you have an application in your solution, and there is an entity added to that application.

You’ve exported that as a managed solution, then you’ve imported it into another instance.

Everything is going well, and, then, some sneaky person (like the one above.. whose picture I’ve found here ) decides to remove that entity from the application directly in the target environment through the default solution:


That plan ends up being a huge success – the entity is gone, it’s not in the application anymore!

But, as it turns out later, there is just no way to add it back through a solution import. You can update solution version numbers, you can try using “overwrite unmanaged customizations” option while importing.. it just does not work – that entity is not coming back to your application. Well, I did not try voodoo magic in my tests.

The only way to fix it is to go to the default solution in the target environment, open the application, and re-add the entity there. After that, you can continue to use managed solution imports whenever you want to remove or add that entity to the application.

So. Dynamics is doing a great job when layering the solutions, when merging them, etc. Do not interfere with this process – if you are relying on the managed solutions in your ALM, don’t do unmanaged customizations in production.