Power Platform and Dynamics 365 explained

I wanted to find a little explainer for someone about what Power Apps are and what Dataverse is and how Dynamics 365 plays into all of it, but I wasn’t able to find what I wanted so I decided to write something on my own.

The current Microsoft Business Applications landscape

This is the way I think of things:

• Dynamics 365 – a brand name for a collection of applications. Just because the app has Dynamics 365 in the name, you can’t imply any sort of relationship of connection with the other Dynamics 365 apps
• Power Platform – a brand name for a collection of platforms / frameworks.
• Dataverse – either a database purpose-built for business applications or the platform for interacting with it. This platform enables low-code building of business apps without having to build your own way to handle business logic, security, relationships, and lots of other things you’d need to handle if you were building an application from scratch
• Dynamics 365 model-driven apps – the first-party Microsoft-provided apps that we all know and love (Sales, Customer Service, Field Service, Project Operations). These are all built on Dataverse, and they all can share the same database. Using more than one of these apps together does not require any type of integration.
• ERP apps – these apps are also included in the Dynamics 365 brand, but they are currently built on completely different platforms (not Dataverse) and require separate integration to interact with the Dynamics 365 model-driven apps.

As you can see, there seems to be a lot going on in the Microsoft Business Applications world and it causes a lot of confusion when trying to talk to someone about Dynamics 365 or Power Platform.

What is a Power Platform developer

I know this question is really niche, but I think explaining it sort of illustrates the point.

From a technical perspective, a model-driven app is a model-driven app. It doesn’t matter if Microsoft makes it or I make it – it’s an app in a solution inside Power Platform. A Power Platform developer or a Dynamics 365 Sales developer or a Dynamics 365 Field Service developer are all pretty interchangeable. There are, of course, going to differences in the features that are developed and managed, but not in how they’re developed and managed.

What is a Power Platform functional consultant

This one’s a little spicier. What makes a good functional consultant, in my opinion, is a firm grasp of the features provided out of the box and how they’re supposed to be used. This is why someone like a Dynamics 365 Sales functional consultant might not be comfortable working in a Dynamics 365 Customers Service environment; while there are lots of shared aspects, there are large differences between the main feature sets of both these apps.

A person who is a functional expert in Dynamics 365 Sales or Customer Service would likely not refer to themselves as a Power Platform functional consultant.

Someone who refers to themselves as a Power Platform functional consultant should have a more general understanding of model-driven and canvas-based Power Apps, but probably is not specialized enough to be considered a “Dynamics 365 Customer Service functional consultant”.

Where do Power BI and Power Automate fit in?

They don’t. Both of these things existed prior to Power Apps even being a thing. They interact with all the apps and platforms listed above, but they do so much more. Both Power Automate and Power BI have access to hundreds of connectors that allow users to access data from both Microsoft and non-Microsoft apps. In my opinion, both tools are at even a higher-level then all the things mentioned above.

Final thoughts

Sorry if this isn’t any better. I just wanted to have a place to point people when I get asked this question again. If you have other thoughts, let me know in the comments.