A few years ago, I wrote a blog about LDD – Licence Driven Development. You can read it here and hear the CRM podcast with George Doubinski discussing the concept here. It covered my thoughts at the time about how our development practices on Dynamics 365 and the Power Platform should be influenced by the Microsoft licensing guidelines. Re-reading it now, some of the conclusions seem out of date, so it seems like a good time to revisit it.
With that in mind, and based on some of my adventures in the past 18 months, here are 10 things you should consider when considering Dynamics 365 and Power Platform licencing.
1. Licence Driven Development is too late
When I first wrote about LDD, I said it stood for Licence Driven Development. An important clarification is that it should stand for Licence Driven Design instead. If you are only considering licencing as part of your development process, the horse has bolted, and the stable has already burned down. Often during the early stages of projects, it’s hard to determine the licencing you need. You are capturing and reviewing a myriad of requirements and trying to align them to SaaS functionality. The customer wants a fixed cost ASAP! Create a spreadsheet with a list of the licences you think you need. Calculate a three-year cost aligned to your requirements as early as possible based on users, data and volumes.
2. It’s OK to mix Power Apps & D365 licences
At the time of writing about LDD two years ago, there were still grey areas around usage of the old Plan 1 and Plan 2 PowerApps licences in conjunction with Dynamics 365. Things have changed a lot since and in a good way. One thing I would recommend you do when trying to design a solution is to always specify one, or a handful of Dynamics 365 licences, even if you are not sure you will need them.
Dynamics 365, Dataverse and Common Dataverse are all different terms for what is effective one and the same thing. Dynamics 365 is a superset of Dataverse, giving you the option to use rich first party D365 functionality. They are both common data services. It’s an entirely valid approach to provision a Dynamics 365 environment with a single licence and create lots of custom entities to only be used by users with the cheaper Power Apps Per App licence, as long as they don’t use these restricted entities. This gives you the flexibility when you get a new requirement to evaluate the first party apps instead of a vanilla Dataverse environment. Ability to upgrade Dataverse to full Dynamics 365 is coming!
3. Consider Storage Requirements up front
In the Azure IaaS and PaaS world, infrastructure architects have long been wary of being stung for compute costs and being inadvertently charged for leaving something running when they didn’t need to. On the SaaS side with Power Platform and D365, this has been something we have been less concerned about. Traditionally you had to worry about the number of users as there was a cost for per user licensing. You may have noticed in the past few years, the cost of Dataverse and Dynamics 365 database storage has increased. You now get an entitlement of 10gb database storage to start off, with additional storage allocated for every user – this can be as low as 50mb for Power Apps users and 250mb for Dynamics 365 users. Any additional storage will have to be purchased as an add-on on a per gigabyte basis.
What this means is, that unless you have a handle on data storage requirements over the next few years, you might have a very expensive solution on your hands. Once you know your user numbers and potential licence types, I like to have an old fashioned spreadsheet that is aligned to the current licencing guide and a current price list – this helps determine how much storage is provided as a base entitlement and how much extra you may need to buy.
You might also need file allocation storage or audit log storage, but in practice this is cheaper and not typically in as much demand as database storage is.
4. Understand Request limits and allocations
Before API Request limits and allocations came along in 2019, I’ve heard it said that there were a small percentage of Dynamics 365 customers who were using most of the resources. Bearing in mind that it’s also been said that Dynamics 365 is the biggest consumer of Azure resources Microsoft have, that’s a remarkable statement and a hole Microsoft had to plug. With the move of everyone to the new Unified Interface in 2021, Microsoft now have a way of accurately metering API calls – and they intend to use it. If you think you only need a Power App per app licence and not a Dynamics 365 licence, consider that with Dynamics 365 licences you get 20,000 api calls per 24 hours compared to a measly 1,000 for an app pass. You need to think about how active your users are going to be. Find out more here.
5. Understand Tiered Add-On Packs
Some Dynamics 365 modules are not provided on a per user basis, but rather on a tiered basis. Power Apps portals are now licenced based on tiered login packs and Dynamics 365 for Marketing is licenced based on marketable contacts in the system, with different tiers based on minimum purchase requirements.
For example, you might work out you need 350000 contacts, so it’s reasonable to think you need 7 packs of 50,000 contacts at tier 4, which has a minimum purchase of 5 packs. That may not always be the cheapest option. Always check and go up a tier – you will often find that buying more contacts than you need – for example 10 packs at tier 5, ends up cheaper and you get an extra 150,000 contacts along with the discount.
6. Power Apps Portals Logins
It’s been written about a lot, but there’s still a lot of people unhappy with the revised Power Apps portals login licensing and the demise of addon portals last year – see here for further details on how it currently works. I continually see confusion with what a ‘per login’ means, which can have major implications for the total cost of a portal solution when there are a large number of users logging in. If you buy a login pack of 100 logins for $200 in a month, and you have 100 different users logging in on a single day, you will have none left for the rest of the month!
Microsoft appear to indicate that this won’t negatively affect a lot of customers, but to a new customer who has a vision of their customers frantically logging into their portal every day, it’s a hard one to quantify. I hope for changes here to encourage new portal customers.
7. Do I need to buy Flow licences?
I get asked a question like this again and again – if I have a 20 user Dynamics 365 implementation, do I need to buy 20 Power Automate packs for each of these users because they’ll be using flows extensively? Generally speaking, the answer is no.
This is because of the concept of Seeded Power Automate. Seeded Power Automate is included with Dynamics 365 User licences. It allows for the provision of unlimited flows if they do not directly or indirectly affect other systems requiring premium or custom connectors. If you are just doing things within the context of Dynamics 365 or Office 365, you are fine. Likewise, embedded Canvas apps can be embedded in Model Driven apps without the need to purchase a new licence or eating into a per app limit you may have.
Likewise, full Power Automate capabilities are also included with Power Apps licences, as long as they are using the same data sources for triggers or actions as the Power Apps application.
8. Don’t forget about non-production environments
You’ve worked out your storage costs, API limits, user licensing and more. What you also need to consider is access to your non-production environments and your strategy for synchronising environments, through either data migration or performing a full clone. The functionality to clone production environments from within the Power Platform admin centre is more mature than ever but if you clone a 50gb environment, you are going to need 50gb extra to store it. Right now, if you run out of storage your end users won’t be affected, but it will restrict your ability to create new environments and perform some other administrative functions. Better to consider storage requirements for non-production up front so you are not scrambling to allocate budgets later.
9. Understand Licensing Agreements and Concepts
There is more than one way to buy Microsoft licences. You can buy them direct from Microsoft, from a Cloud Solutions Provider or as part of a volume licence agreement. Depending on your channel, this may mean you can buy licences on older agreements, for a limited period of time, with historical entitlements that new customers can no longer buy. For that reason, it might be more appropriate to check your entitlements by referring to an old version of the Microsoft Licensing Guide rather than the latest and greatest.
Remember, there are different rates for charities, academic and corporate customers as well as discounts available periodically, so don’t always assume you will pay the headline rate.
For a 3 minute crash course on licensing concepts, see my explainer below.
10. Ability to Do ≠ Entitlement to Do
Many customers used the old Dynamics 365 Team Member licence as a XRM development licence. That approach has now finally been put to bed with the technical enforcement of team members being restricted to a single app with a 15 entity limit. This teaches us a wider lesson however – just because you can test something and verify it works with a licence, does not mean you are entitled to do it. It’s great that Microsoft are enforcing the licensing because it makes drawing the lines better, but don’t yet rely on enforcement. Read the licensing guides and ask for advice from someone who understands the practicalities as well as the licencing theory!
If you have any other tips, please get in touch – this is my take, I am not a lawyer. By the time you read this blog, it may well be out of date!
Footnote : Apologies to my international readers who prefer license! 😉
Brian Illand 