Can Dynamics 365 Sales or another module be replaced with Power Apps? Hidden licensing risks worth knowing.
This week, we spoke with a prospective customer who was looking for ways to optimize their Microsoft licensing costs. During the conversation, it turned…
This week, we spoke with a prospective customer who was looking for ways to optimize their Microsoft licensing costs. During the conversation, it turned out that they had already received a recommendation from their current provider – a company with many years of experience in the market. The recommendation was to gradually replace standard Dynamics 365 CRM functionality with custom Power Apps built on Dataverse and standard entities. The suggested starting point was service processes, with sales processes to follow later.
I listened with my eyes wide open. Either someone here does not fully understand Microsoft licensing rules, or they simply did not tell the customer the whole story.
From a technical perspective, the idea is feasible. Power Apps offers a great deal of flexibility, Dataverse is a robust platform, and a Canvas App can be built to look and behave almost like a native CRM application. The problem begins precisely at the point where the application starts looking and functioning like Dynamics 365, because Microsoft has a very clear licensing position on that scenario.
And that is exactly what I want to write about. Not to discourage the use of Power Apps – it is an excellent tool, and we use it regularly ourselves. Rather, I want to show where cost optimization ends and where risk begins – risk that can ultimately become very expensive.
„If we can build our own application (CRM) in Power Apps and use Dataverse as a database – why do we need a Dynamics 365 license?”
The question sounds reasonable, and I understand where it comes from. Dynamics 365 licenses can constitute a significant portion of a project, and in subsequent years, a visible portion of the IT budget in reports. On the other hand, Power Platform tempts with its flexibility and lower costs, enabling the rapid development of business applications. Dataverse provides an advanced data layer, and licenses are significantly cheaper. Therefore, at first glance, the idea seems very attractive: we can build our own solution tailored precisely to the organization’s needs, but using standard entities known from Dynamics. The problem is that half the time this calculation is incorrect. This isn’t because Power Apps is a bad tool, but because Microsoft licensing doesn’t work as most people intuitively assume.
Where does this idea come from?
The pattern is always similar. An organization plans to implement or adapt some process(es). It starts with a cost analysis, and at some point, someone looks at the Dynamics 365 price list and says, „This is a big budget line item.” A moment later, the idea comes up: „We have Power Apps, Power Automate, Dataverse, and Power BI. We can build this ourselves.” And that’s where the problem begins. Because technically, and I completely agree, they’re right. It’s not fantasy. Using the tools mentioned above, you can build very good applications. Power Platform is flexible enough to replicate much of the functionality of Dynamics 365. Someone simply looks at the problem solely through the lens of technology, omitting the question that should be asked first: is this approach compliant with Microsoft licensing policies? And this question rarely arises when the idea is still fresh and everyone is excited about the potential savings. It arises much later – sometimes only during an audit.
Technology and licensing are two different worlds
Most people assume that licensing depends on the application the user is working in. If I’m not logging into Dynamics 365, I don’t need a Dynamics 365 license. It sounds logical, but Microsoft doesn’t see it that way. Microsoft doesn’t care what window the user sees. What matters is the functionality they’re actually using and what data they’re interacting with. Is it handling service requests, creating quotes? Managing queues? Monitoring SLAs? If so, it’s within Dynamics 365, regardless of whether they do it through the native interface or a custom-written Canvas app. This isn’t an interpretation. It’s explicitly written in Microsoft’s licensing terms.
What is "multiplexing" in Microsoft licensing?
Microsoft calls the situation described above multiplexing and has a very clear stance on this: you can’t reduce licensing requirements by adding an additional layer between the user and the product. It doesn’t matter whether that layer is a web portal, a mobile app, or a custom-written Canvas app in Power Apps. If a user indirectly uses Dynamics 365 functionality, they are treated the same as a user who logs in directly.
This is a rule that operates regardless of intent. You might not realize you’re violating it, but you might be convinced you’ve found a clever workaround. An audit verifies facts, not intentions.
What exactly is this multiplexing about? Restricted tables.
In Dataverse, some tables are marked as restricted to specific Dynamics 365 licenses. In the service area, we’re talking about tables that are at the heart of every customer service process: Case, Entitlement, SLA, and Work Order. In the sales area, the list is equally specific: Opportunity, Quote, Order, Invoice, Lead – the very tables that underpin every sales process. While a user with a Power Apps license can read data from these tables, creating, updating, or deleting records requires a corresponding Dynamics 365 license. Not Power Apps Premium, but Dynamics 365.
And this is where many projects start to fall apart during the licensing analysis phase. The Canvas app is ready, looks great, and works exactly as expected and then someone checks which tables they’re using, and it turns out the whole idea of saving licenses is no longer viable.
Let’s go back to the client we spoke with this week. The plan was to gradually replace Dynamics 365, starting with service processes and ending with sales. In practice, this means operating on restricted tables from both areas. In essence, every key table that has business significance in Dynamics 365.
The mechanism is simple: Microsoft doesn’t look at the interface. It looks at the data. If your application reads and writes to tables that are part of a licensed Dynamics 365 solution, you’re in the Dynamics 365 space, regardless of how different your application looks from native CRM.
Therefore, before making any architectural decisions, it’s worth asking one very specific question: what tables will this application operate on? If the answer includes Case, Entitlement, SLA, Opportunity, Quote, or Order, the licensing discussion must take place before the first line of code is written.
When is Power Apps a safe choice?
To avoid any misunderstandings, I’m not saying that Power Apps is a bad approach. On the contrary, we use it regularly and see how much value it can deliver.
Thousands of organizations are building solutions in Power Apps that have nothing to do with Dynamics 365 – fleet management systems, HR applications, equipment records, audit processes, compliance tools. And they do it completely legally, relying on their own Dataverse tables, their own business logic, and their own processes. In such cases, a Power Apps Premium license is perfectly sufficient, and no one has any objections.
The line is clear, though not always obvious at first glance: if the application doesn’t touch Dynamics 365 functionality or data, you’re safe. The problem begins when you start building something that functionally resembles CRM, uses its tables, and replicates its processes – just in a different package.
The cost of a license is only part of the equation
Even if someone finds a way to resolve licensing issues and does so fully in accordance with Microsoft’s policies, there’s another side to the equation, one that’s much less discussed.
Dynamics 365 isn’t just about licensing. It’s a product that Microsoft has been developing for years and regularly investing in-new features, security updates, integrations, AI mechanisms. By purchasing a license, an organization also buys into this development. When it decides to build its own solution, it assumes full responsibility for it.
In practice, this means that every new business need is a development project. Every process change requires team involvement. Every issue of security, access control, or regulatory compliance rests with the organization, not the vendor. And the features that appear in Dynamics 365 updates – Copilot, automation, new routing mechanisms – must be designed, built, and maintained in your own application.
This isn’t an argument against building your own solutions. It’s an argument for calculating the full costs. I’ve seen projects where licensing savings reached tens of thousands of PLN per year, and the cost of maintaining your own application exceeded this amount several times over after two years. A decision that looked like optimization on paper turned out to be more expensive in practice than what they were trying to avoid.
How to approach the topic responsibly?
When a client comes to us with such an idea, we ask them a few questions. Not to discourage them, but to mutually understand what we’re really dealing with.
The first question is always about processes: what exactly do we want to support, and are these processes truly unique to this organization, or do they simply resemble standard Customer Service or Sales? This question is often eye-opening, as many organizations believe their processes are unique, but in practice, Dynamics 365 supports them out of the box, without a single line of customization.
The second question concerns data: what tables will the application operate on? Custom entities or standard Dynamics 365 tables? This question, as I’ve already mentioned, often ends discussions about licensing savings before they even begin.
The third question is the most difficult, because it requires a bit of honesty: are we solving a real business problem, or are we primarily trying to reduce licensing costs? Both can be valid goals, but when cost optimization becomes more important than architecture and business needs, projects often end badly.
And finally, the question of money, but calculated honestly. Not „how much will we save on licenses,” but „what will the total cost of the solution be in five years, including development, maintenance, support, and everything else we get from Microsoft today.” This calculation often changes the perspective.
The last thing we always recommend before starting a project: a formal licensing interpretation. Not the opinion of a colleague in the industry, not a LinkedIn post, not the assumption that „it’s probably OK.” Verification with Microsoft or a specialized licensing partner. This step costs the least of all and is most often overlooked.
Summary
Let’s go back to the client who started this article.
We didn’t discourage him from using Power Apps. We didn’t say the idea was bad. We said that before making a decision, he needed to answer a few specific questions – about processes, tables, full costs, and licensing interpretation. Because if these answers are correct, Power Apps could be a great choice. If they aren’t, changing the interface while maintaining the same data and processes isn’t an optimization. It’s a risk that will only become apparent during an audit.
Advising customers to replace Dynamics 365 with their own Canvas app sounds appealing on a slide. In practice, it requires more than technical feasibility. It requires an honest licensing analysis, a full cost calculation, and the understanding that Microsoft doesn’t look at what the app looks like, but at what it does and what data it runs on.
A good solution doesn’t have to be the cheapest upfront. It must be honestly calculated, compliant with the manufacturer’s policies, and ready to operate in five years, without surprises.