Power Platform | Power Apps or Dynamics 365 or both?

I recently came across a couple of conversation around the same topic – Will a Power Apps license be enough to run Dynamics 365? Not sure why this became a big topic in the last weeks, maybe due to cost considerations, maybe some solution architects brought up that idea on Twitter? Anyhow, I thought the answer should be easy – just take a look into the license guide and every customer should know when to go with Power Apps or Dynamics 365 licenses.

But truth is, neither latest Power Apps licensing guide, nor Dynamics 365 licensing guide is providing a simple answer to this question. Furthermore, there´re some myths outside that customers must struggle with the answer. Want to know some of them?

I started reaching out to my good old friend Chris Huntingford asking if he came across this as well. To my surprise we´ve been addressing the same topics side by side without knowing. But without further details, let´s hop into content we aggregated, starting with a simple definition first. Above visual shows two houses and my challenger question would be: Where´s the difference?

People would start taking a deeper look into both images, trying to find a window with a wrong shade, a false angle, or any other difference. [Believe it or not, both are the same]

Next, we would outline that both houses share the same base – rock-solid, which is Azure as Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) level. On top of this the Software as a Service (SaaS) layer is what we would typically see and where you would categorize both Power Apps and Dynamics 365 with. But more recently, we´ve seen a category aPaaS (Application Platform as a Service) in between that better describes the Power Apps offering. Another good old (MVP) friend of mine Jukka was already talking about this here. Anyway, back to the roots, Chris and I thought: Very high-level and very technical, isn´t it? So we asked if there´s an even better way to help distinguish between Power Apps and Dynamics 365?

Of course the answer to this is looking into more details. Whereas Power Apps main purpose is to either built from scratch or start with a template, Dynamics 365 1st party applications simply would be installed, configured and then would be ready to use.

Those feature-rich applications contain pre-built business logic which makes those apps a perfect fit for specific business processes. Furthermore, those IP is currently protected using restricted entities. [In other words: Specific entities would force to have a Dynamics 365 license instead of a Power Apps license only]

Though above linked article is listed as out-of-date and you should visit the Power Apps licensing guide instead to find answers on licensing requirements by entities, you will figure out that it references back on the restricted entities article. Puzzled? Yes, we all agree that it needs a better way to address the protection of Dynamics 365 licensing. But the real issue is the myths on features, that some advisors would classify as forcing a Dynamics 365 license, which in fact are not or no longer.

So features like the App for Outlook, Server-side Sync and Exchange Integration, SharePoint Integration, Document Templates, Microsoft Teams Integration or even Plug-Ins are also included with a standalone Power Apps license. In fact, Power Apps Product Group just posted a reminder on their blog site here.

Why – you would think – should I have a Dynamics 365 license then?

Chris and I put together a real-life example. The true Power-House is to allow the license mix between front-end and back-end usage on typical solutions, such as:

  • Facilities Management
  • Fleet Management
  • Inspections
  • Logistics or Supply Chain Management

Those solutions typically can be split into front-end users that would have lightweight access points on some parts of the solution, such as uploading a photo, adding notes, adding details and back-end users that takes care of business processes, such as case-routing, knowledge-base article creation, work-order creation or resource scheduling.

What all of those solutions have in common is a mixture of 60:40, 70:30, 80:20 or even 90:10 ratio of users assigned to either front-end or backend-roles. Well, instead of building the application needed for backend users, you will figure out that Dynamics 365 1st party apps are already a good fit. They can be easily deployed and used, but for rolling those out across organization it might become an issue.

And here´s the beauty of the license mix. Building task-based front-end apps with a subset of features, but perfectly matching the needs of front-end users. Let´s look into one of the above examples in more detail.

Here you can see a Facilities Management solution that consists of two major solutions. One is containing custom entities that would be needed for both front- and back-end users, but also contains canvas apps and/or model-driven apps for front-end users + any business processes or flows needed for them.

A second one contains additions to entities that would be shipped with Dynamics 365 1st party applications, such as FM-specific fields added to the case or work-order entity. It also contains all kind of back-end typical business process flows, case creation rules, etc.

By layering both solutions, the overall resulting solution is one Facilities Management solution that can be used by both front- and back-end users in a license mix, without violating any given license restrictions, such as CRUD (Create, Read, Update, Delete) permissions.

Therefore, distinguish between Power Apps and Dynamics 365 in many situations is not what the solution architect should recommend. It should be pretty common instead, to have a license mix, use solution layers that merge into single or at least linked solutions with a harmonized Common Data Model inside the Common Data Service.

That´s all for now, until next time

3 Gedanken zu “Power Platform | Power Apps or Dynamics 365 or both?

  1. Pingback: Power Platform | The Make vs. Buy paradox | The Power Platform Talks
  2. Good article Carsten. I agree with this. The area that’s still not clear for me is the Front Office Update Cases vs Back Office Process Cases in your last graphic. What do you see as the difference between ‚Update‘ vs ‚Process‘ Case? I find the license guides rather vague in terms of the restricted entity rules. I guess it’s about leveraging the Customer Service 1st party features such as Auto Case Creation & Routing Rules from the back office app, which wouldn’t be available if none of the users had Customer Service licenses?

    • Correct, unless you’re leveraging features that are related to 1st party apps, such as CS, you would need to have the full license. That’s why in many situations you can build front-end and backend solutions in a mix which also makes it more attractive in using them

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:


Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )


Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )


Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.