Here’s a collection of recent questions from the Dynamics 365 and Power Apps use community on licensing topics. The answers are my own interpretations, based on what I’ve seen from MS or other community members. It’s a point-in-time blog post that may well be outdated tomorrow already. Please do also leave a comment if you see errors in the answers I’ve written.
As always with enterprise software licensing, ultimately the answers need to come from materials published by the software vendor, i.e. Microsoft. At the end of the day the customer is always responsible for being compliant with their own legal agreements that may have specific terms included.
Team Members
Q1: What’s changing in the 2020 Release Wave 1 for users equipped with Dynamics 365 Team Member license?
The release plan contains several items that talk about licensing enforcement. So, the actual rights for Team Member licenses are not changing, but there will be technical limitations on what the users are actually allowed to do. I’ve blogged about the underlying mechanism for linking service plans to application types, which will first be used for Team Members and down the line probably also for other licensing types.
2020 Release Wave 1 will introduce three new App Modules with pre-configured experiences for Team Members: Sales Team Member, Customer Service Team Member and Project Resource Hub. See my review of the early access version of these New Team Member Apps for Dynamics 365 for more details.
Q2: When will the technical enforcement be enabled in our Dynamics 365 environment?
For new customers, Microsoft intends to switch on the restrictions in April 2020. For existing customers with Team Member users, the change won’t happen overnight. Expect to see further communication from MS on this if your organization is affected by the changes.
Update: On Feb 24th Microsoft published the following “Dynamics 365 – Team Member License Enforcement Notification” in the Microsoft 365 Message Center (MC204622) visible to administrators:
To facilitate a smooth transition to the new Team Member app experiences, all existing customer organization instances, which will be impacted by this change, will be granted an additional grace period until June 30, 2020.
Update 2: due to COVID-19, Microsoft has postponed several deadlines for updates and deprecations. The latest guidance for Team Member licensing enforcement is now:
To facilitate a smooth transition, all customer organization instances that are created before April 1, 2020 have been granted an additional grace period until January 31, 2021.
Q3: The entities we use with Team Member license in our environment are not included in the standard apps, can we add them?
Yes. Customizing the aforementioned App Modules is allowed, as long as you follow the instructions given by Microsoft:
“Team Member apps can be tailored to more closely fit your organization’s industry, nomenclature, and unique business processes, just like other model-driven apps built on Common Data Service. However, these customizations will need to conform to the Dynamics 365 Team Members use rights detailed in the licensing guide. While customizing the app, you can add 15 additional entities. These additional entities can be any Common Data Service core entities, or you can create custom entities.”
Q4: The new Team Member apps ship with dedicated security roles. Does it mean we’re only able to assign these to the TM users and nothing else?
There is currently no restriction on what roles you can assign to users with a Team Member license. The way I see it, the OoB security roles are primarily used for granting access to the App Modules and stripping down features within the app that are not within the original design scope.
Q5: If we need users to access more than 15 entities, what are our options?
The App Modules for Team Members will technically enforce a limit on how many entities can be added. Now, keep in mind that the App Module itself doesn’t restrict what’s actually visible in the UI when looking at an entity form. For example, an account form can have many related entities shown that are not part of the App Module specification. If you don’t directly need to navigate to the entity but rather use them to describe properties of the main entity (say, account plans related to an account), then there might not even be a problem here.
If you need to browse through lists of tens of different entities, then you’re really pushing the boundaries of what Team Member licenses are intended for. Anyway, you could consider alternative access mechanisms alongside the Unified Interface App Module to cover these scenarios. Reporting tools could be a better way to present large quantities of data that are going to be read-only for the users. By purchasing a Power BI license for users that are equipped with Team Member licenses already, you would have full access to read the business data in CDS via reports and dashboards – as well as use Power BI for any other analytics needs within the organization.
Q6: Our users are accessing data mainly via the Dynamics 365 App for Outlook, is this going to be available to Team Members?
Yes. The Licensing Guide specifically lists this as the first use right for Team Members in Appendix A: “Access Anywhere: Web App, Mobile App, Tablet App, via Outlook.”
Q7: Can we also leverage Canvas apps with the Team Member license?
Yes and no. You can use embedded Canvas apps within a Model-driven app entity form, since these are just customizations within the app itself. However, you can’t access standalone Canvas apps with just a Team Member license.
Q8: What about if we have Office 365 license that gives access to Power Apps AND a Team Member license, could we then build a Canvas app that reads Dynamics 365 data?
Probably not, as this would require access to Premium Connectors. The CDS Current Environment Connector is the only non-deprecated way to access Dynamics 365 data (in the “product formerly known as Customer Engagement”, not talking about Operations or Business Central here), so this will likely be the technical blocker that stops you from building the custom app.
Power Apps
Q9: If we were to move our licenses from Team Members to Power Apps per App plan, what will the main differences be in the user experience?
Power Apps licenses are meant for custom apps, meaning there will not be a preconfigured App Module from Microsoft. That’s no big deal, since creating new Model-driven App Modules is very simple. You can choose the entities you need in the app, design a sitemap to provide the navigation experience for accessing these, give your app a name, hit “publish” and have a custom App Module available to the users. There aren’t any fundamental differences between what a Sales Team Member app and “Our Customer Management app” look like to the users, as they’ll all be Model-driven apps presented via Unified Interface.
Q10: Are there still restricted entities in Dynamics 365 that you can’t access with Power Apps licenses?
Yes, there are, but no one knows exactly which entities. We are still waiting for Microsoft to update the list of Restricted entities requiring Dynamics 365 licenses, to align with what was supposed to be the October 2019 licensing model update. Eventually there will be new information published, but the current situation is quite challenging for both customers and ISVs to navigate past the Power Apps potholes.
Compared to Team Member rights, a Power Apps premium license grants you access to create-read-update-delete (CRUD) entities like accounts, leads and opportunities that are read-only for Team Members. Also there are no 15 entity max limits in the Power Apps world, so your custom app can have a CDS data model that’s very complex. When you’re working with entities you create yourself, there are no restrictions at all. When you touch something built by MS for their first party apps, there’s a chance that limitations will apply at some point.
Q11: If we would like to allow also external users to access Power Apps in our tenant, can we do that without buying a Power Apps Per App Plan or Per User Plan for everyone?
With Canvas apps, there is the option for “bring your own license” (BYOL) available, which I’ve covered in this blog post. For Model-driven apps, this isn’t possible today. Power Apps Portals is always an option if you’re willing to re-build your app as a portal UI. (See also the Capacity topics below.)
Q12: We’ve bought Power Apps per App Plan licenses for our users, now how do we assign these to the custom Model-driven app we’ve built?
This is currently a tricky process, since Microsoft is still working on the proper mechanism to associate app passes with Model-driven apps. Follow these steps published on Magnetism Solutions blog and you should be able to pull it off. The Canvas app side is much easier and better documented by Microsoft.
Q13: It seems that we can’t assign the app passes to both our production and test environments. Is this a bug or a feature?
It’s a feature. While Dynamics 365 licenses like Team Member grant access to any number of environments in your tenant, the Per App Plan is actually a “Per App Within an Environment Plan”.
Q14: From a licensing perspective, what are the differences between a Dynamics 365 environment and a pure CDS environment without Dynamics 365 Apps?
Power Apps users can access any environment, if they have the Per User Plan or a Per App Plan app passes assigned in that environment. Dynamics 365 users are only allowed to use environments that have one or more Dynamics 365 Apps installed. So, if you build a small expense tracking app in a pure CDS environment, a user with $10 or $40 Power Apps licenses can use it, but a user with a $95 Dynamics 365 Enterprise App license can’t.
Q15: If we start with a pure CDS environment to build a custom data model for our custom apps and later want to add a Dynamics 365 first party App from Microsoft, how does that work?
Today you can’t deploy Dynamics 365 Apps into a pure CDS environment, so the only way would be a data migration project from your CDS environment to a new Dynamics 365 environment. It’s a technical limitation that MS surely wants to remove at some point, but right now you can’t step up from custom app to first party app via a license purchase alone.
Capacity
Q16: We want to build solutions that go beyond the personal productivity apps that the Default Environment is really only good for. What do we need for adding more environments, to leverage CDS and do proper ALM?
Creating a new environment requires database storage capacity, since every blank environment consumes 1 GB before you even store any data there. This is the only cost associated with environment creation, you don’t need any instance licenses for sandboxes anymore like Dynamics 365 used to require earlier.
If you purchase even a single Dynamics 365 license or a Power Apps Per User Plan license, you’ll get the 10 GB default capacity for database storage. If you only purchase Power Apps Per App Plans, it’s 1 GB. Each additional user accrues 250 MB more, if you buy Dynamics 365 Enterprise Apps or Power Apps Per User Plans. With Power Apps Per App Plan or Power Automate Per User Plan the users only accrue 50 MB. With Dynamics 365 Team Member or Professional App licenses, there’s no accrual per user.
The default environment already burns 1 GB of your database capacity, so creating new environments may not possible without buying a capacity add-on license – unless you’ve bought one license that increases your default capacity to 1o GB (hint: always buy one).
Q17: We have integrated other systems with Dynamics 365 / CDS and are now worried about the cost of API calls. How much will we have to pay for these?
If the integration is accessing CDS as a non-licensed application user, the number of API calls that you have available for free is determined based on the types of licenses in your tenant. With at least one Dynamics 365 Enterprise App user, you get in total 100k requests per 24h, every day of the month. With Professional licenses this falls to 50k and with Power Apps / Automate it’s 25k. Anything beyond that requires buying dedicated capacity add-on licenses.
Now, even though you can buy the license already, you can’t assign it yet. Since there also isn’t any API usage telemetry available to customers yet, we’re not in a situation right now where the system usage would be technically limited based on overage.
Q18: Power Apps Portals, is the login capacity license starter level of 100 logins / $200 per day or per month?
That’s 100 logins per month. A login session lasts 24 hours, after which a new login is consumed from the licensed capacity. If a user logs in every first day of the month, that’s a $2 per month cost. If they log in every working day of the month, the cost would be around $20 per month for Portal access, which is twice the price of a Power Apps Per App Plan. For higher volumes of Portal usage, there are discount tiers available to bring down the costs. Note that you need to purchase a sufficient amount of capacity in advance, based on how many logins you expect to have in any given month, because unused capacity does not roll over to the next month.
There’s more!
I’ve written several blog posts about the licensing topic, which you can browse through right here. If you want to keep up with the latest news around Power Platform, please feel free to subscribe to the Thinking Forward blog updates.
Hi Jukka,
Great summary – thanks!
Given the current limitations of D365 licensed users not being able to access a Powerapps instance, while powerapps users can access a D365 instance, what would in your opinion be the reason for creating Powerapps instance over a D365 instance?
Mikkel, that is a good question. The model as it stands really does encourage you to put Dynamics 365 apps in all provisioned CDS environments “just in case”, since this offers A) access rights to a wider set of licensed users and B) the ability to step up from custom apps to MS first party apps without a data migration. We can only speculate if in the future there would be limitations for Power Apps licensed users to access environments with Dynamics 365 apps.
Great post, Jukka – it’s really helpful when doing a license review.
We are probably going to convert our team member licenses to Power Apps per App licenses. However, we are also considering converting some of our Power Apps per user licenses to Power Apps per app licences as they are only using a single app. But that raises some questions regarding the API call limits for users.
According to the Power Apps and Power Automate licensing FAQs (https://docs.microsoft.com/en-us/power-platform/admin/powerapps-flow-licensing-faq), Power Apps per app users only get 1.000 API requests / 24 hours compared to the 5,000 that Power Apps per user get. Moreover, API capacity is tracked based on consumption at an individual user level, and the daily limits cannot be pooled at any other level.
Is the best indicator of individual user’s API calls, right now, the Common Data Service analytics in the Power Platform Admin Center? It shows the CRUD operations for the most active users but I’m not sure if all of the calls our counted toward that limit, cf. this blog post by Scott Durow (http://develop1.net/public/post/2019/09/04/how-do-the-powerplatform-api-limits-affect-model-driven-apps).
Moreover, does it count API Calls performed via Power Automate or do we need to look at connector calls in Power Automate analytics?
You probably can’t answer these questions – but it just seems so weird to apply limits without us having anywhere to measure if we are actually going over the limits or not. And even though they’re not going to technical limit use of the system if you go above the limits – it makes it really hard to know which license to buy.
Niels, you are correct in your assumption that there currently isn’t an answer available 🙂
Microsoft hasn’t yet been able to publish the reports and monitoring capabilities for the API limits. Therefore it is in practice impossible to know how many API calls the typical end user of a specific app would be consuming. What MS has stated is that the intention behind the model is that normal customers shouldn’t have to worry about the API calls, i.e. the app/user licenses should cover it. Where the API calls will certainly have an impact is the automated use via integrated systems, such as large data syncs or frequent web service calls. Protecting Power Platform from potential abuse of cheap compute resources via a single end user license is one of the main reasons for the new model to exist. Yet at the same time, due to how these licensing changes have been rolled out, naturally any customer who is aware of these limits will be wondering about their impact.
Hello Jukka,
Thank you many questions are answered here. I have another one which Microsoft Support hardly understand regarding how Dynamics Marketing and Team Member work along…
A company has 10 Dynamics Sales Enterprise and 5 Team Members. This company has Dynamics Marketing too.
Dynamics Marketing is licensed per organization.
According to the license guide Appendix B: Customer Engagement Application Use
Rights, unless I am mistaken, I can see that user with Marketing App can update create Accounts.
Then a Team Member user can access Marketing App and update account through this app? Or is Marketing App only accessible to Full licenses?
Same question for Activity Users who are able to read Dynymics app the same.
Thank you very much for you highlights, this is question is open for month downhere.
Best regards,
Pierre-Olivier
Pierre-Olivier, that’s a very interesting scenario. Based on the Dynamics 365 Marketing documentation, “Any user who already has a license for any model-driven app in Dynamics 365 also will be able to access Dynamics 365 Marketing without requiring any additional licenses.” So, I believe there is nothing stopping users with a paid Team Member license or the free Dynamics 365 Marketing User License to access the Marketing App Module, where according to the Licensing Guide there is Create, Edit, Update rights specified for the account entity. Now, keeping in mind that the technical enforcement of Team Member licensing is not on the security role level but on App Module access level, my interpretation is that the company is entitled to assign all their user a Marketing security role that would grant access to the account entity. With this security role in place, also the Sales Team Member app would allow full CRUD features to accounts.
Thank you for this FAQ, Jukka. I have one question – do you have any idea what could happen in case that team member is assigned a security role which grants him CRUD on more than 15 custom entities or allows him to edit accounts?
What could happen is that the organization is then no longer in compliance with the terms of their license agreement with Microsoft. There will likely not be technical enforcement that blocks you from this operation today. However, it’s good to keep in mind that everything may well leave a trace in the telemetry data collected in Microsoft’s cloud. So, even though much of the software licensing is still on an “honor system” today, it will become increasingly data driven in the future.
Great blog!
D365 Licensing Guide 2020 document, mentions that Team Members license is limited to personal use only. Including that section below:
“Team Members use rights for Customer Engagement Applications
The Team Members User SL grants a user the following Sales, Customer Service, Field Service, or Project Service Automation rights for their own use and not for, or on behalf of, other individuals:”
Wasn’t able to get a clear answer for this from Microsoft so far.
What is your interpretation on this statement?
Lorenc, I believe it refers to performing data updates that are about the individual himself/herself, as opposed to administration work that an assistant might perform on behalf of other users. For example, “Record time and expense for Project Service Automation, and apply for projects” as a right is about the Team Member being able to record own time entries, but not entering time data for the whole team. So, records where the user is the owner (like own tasks) could be appended to other records owned by different users (an account owned by a key account manager).
So here’s an interesting scenario. One of my clients have team member licenses, but have installed a CDS environment, rather than Dynamics. Seemingly, a CDS environment won’t get these new apps and we can’t seem to be able to install them on the environment either. Do you know of any way to get around this? 🙂
Otherwise, I think my best bet is to move them to a per-app Powerapps license.
Mikkel, since none of the Dynamics 365 license types allow using a CDS environment without Dynamics 365 Apps installed, and since this installation path is not supported by Microsoft, there is no workaround. Here’s the text from the August 29 announcement about changes in October 2019 licensing terms for Dynamics 365:
“Dynamics 365 subscribers may continue using PowerApps and Flow to extend and customize their Dynamics 365 applications. However, Dynamics 365 Enterprise licenses will no longer include general purpose PowerApps and Flow use rights. Dynamics 365 Enterprise application users can continue to run PowerApps applications within their Dynamics 365 environments, but running PowerApps applications in non-Dynamics 365 environments will require a PowerApps license. An additional Flow license will also be required to run flows that do not map to a Dynamics 365 application.”
Awesome post! Some follow up question on the API limits.
1) Is there any information as to pricing of the add-on capacity for API calls? I can’t find anything.
2) Can we trust the API calls counter in admin center?
3) When will these limits be enforced? Are they already being enforced for new customers?
Per, to answer your questions:
1) Pricing can be found on the Power Apps and Power Automate licensing FAQs page Add-ons section.
2) I wouldn’t trust them.
3) See question “What happens if any user exceeds Request capacity?” on Requests limits and allocations page.
Jukka,
The installation I am working on with looks like its going to have to be convereted from Team Member licenses to Powerapps P1 (Per App) licenses, But some users are accessing the Case entity which is on the restricted list.
Any idea what happens if a PowerApps “Per App” user acesses a “restricted entity” .
Also, will those users accessing the Case entity need a full Dynamics Enterprise license.
Last question on API limits. Documentation states that there will be a transition period until October 1st or until expiry of current subscription. Say a customer renewed their license on the old terms last autumn, then their transition period won’t end until autumn 2022 (given a three year license period). Confusing…
In an organisation with limited use of the case entity, it seems to me the best approach is to use Team member licences and a Power Apps licence. The power app can handle the account/lead etc. entities which are not covered under the Team licence, and any overspill from the 15 entity limit.
And then a handful of full licences can be purchased for those users who need to create/update cases, and maybe some superusers who need complete entity access.
That would work out at $20pm instead of the $95 or so a full licence costs.Even a full power apps licence at $40 would be half the cost.
How would bought in solutions be handled, such as Click Dimensions? They come with their own apps. Would they require a full licence you think, or can count as one of the apps allowed under the power app plan. I believe the Outlook app works this way, using one of the power apps. So if an organisation used the Outlook app, the Click Dimensions app and a model driven app for accounts/leads, would that not work as it is 3 apps – or does the Team licence include the Outlook app!
If the organisation goes full board with all users utilizing power apps (Power Apps per user plan), then it would make sense for the power apps environment that would be used to be the Dynamics production environment, thereby saving on Dynamics licensing as the addon model driven apps will be covered already. Storage costs may need to be looked at in this scenario.
Great comment from Mark! Just a small detail: Team Member license does not grant full use rights of the case entity, only the self-service scenario (for which the built-in Customer Service Team Member App Module is now geared towards). So, at a minimum you need the Professional license for Customer Service or Sales (latter with less advanced service functionality), or Enterprise if you have to go beyond the 15 entity limitation.
Hi Jukka, great post again.
I have a query regarding Power App licencing and access to the Case Management entities that I was hoping you could provide your opinion on.
if we look at a hypothetical scenario of an internal service desk customer power app. As the Case entity is now not a restricted entity, I think it would be possible to user a Power App licence to allow support tickets to be created. However SLA and KB are still restricted, but most users of the system will only read KB articles so that is fine. In relation to SLA’s, as long as I have i user with a full first party app licence would to manage the SLA’s then would that work. Or am I pushing my luck there.
Is there any restrictions on mixing licencing on an environment, for example team member, power app, first party?
thanks for your help and all the work you are doing to make MS licencing a little clearer for us all.
thanks
Paul
Paul, I’m not sure from where you’ve received the information that Case would not be a restricted entity, as based on Microsoft documentation it still is. Please note that the Restricted Entities concept does not relate to Team Member licensing but rather Power App licensing. I don’t think there’s any scenario where you could apply a Team Member license for elevation of privileges, as the Power Apps Canvas apps will most likely check the access rights against the “real” Dynamics 365 App licenses. Team Members should be considered a license type meant for the specific scenarios outlined by Microsoft, so my advice is not to acquire that and expect to have further doors opened in terms of what you can do on the CDS side. The opposite way is a much more valid scenario, meaning switching from Team Members to Power Apps Per App or Per User licenses, as you’ll regain the ability to use custom App Modules – as well as Canvas apps, of course.
Hi Jukka, thanks for your response
Unless I have mis-understood the update from Microsoft they announced the following late last year
“Updates to Dynamics 365 licensing
Dynamics 365 is moving from the multi-application, one-size-fits-all Customer Engagement (CE), Unified Operations (UO), and Dynamics 365 Plans to individual applications that allow customers to buy just what they need, when they need it.
We are making refinements to restricted and unrestricted entities with the goal of enabling more users to access data directly through a PowerApps application or Flow workflow without requiring a Dynamics 365 license. The case entity will now be available to PowerApps and Flow users to create, read, update, and delete. Select Dynamics 365 for Sales entities will be added to the restricted entities list.”
https://www.microsoft.com/en-us/licensing/news/updates-to-microsoft-365-dynamics-365-powerapps-and-microsoft-flow-licensing
thanks
Paul
Paul, I have seen that announcement, but I’ve also seen how Microsoft has never made the announced changes into their actual licensing documentation. It’s now been almost half a year since the new licensing model of October 2019 has supposedly been in use, yet from what I know, there isn’t a single soul outside Microsoft that has had acces to a revised list of the Restricted Entities. There were also other types of licensing news published in the partner channel during the summer of 2019, but until they are made public in the licensing guides and/or Docs pages, I would consider these merely as plans. Plans can change, and I believe this what has happened to the Restricted Entities definition.
Excellent post (again) and blog Jukka!
What I find difficult to be sure of, are the licensing requirements when you have a mix-breed app so to speak. What I mean by this is a case of first having a good old Dynamics environment with a couple of 1st party apps. If I then proceed to building my own custom model driven app in the same environment, and I include bits and pieces from those 1st party apps to that new app, how can I determine the licensing requirements for using my new app.
I find it a little difficult to draw the line on when a power apps license is sufficient for a custom app, and when a D365 license (or two or more) is required, when operating in an environment where there’s already one or more D365 1st party apps installed.
Or is it so straightforward that those Microsoft 1st party app licenses would also be required for the new app as well, as it takes advantage of some of the functionalities built by Microsoft?
Thanks!
Ana, there has not been any clear communication from Microsoft around this scenario where the app crosses the boundaries of the two product lines (which is one of the prime reasons for Power Platform licensing complexity). I have covered this topic in an earlier blog post, “Power Apps licensings and a Dynamics 365 environment”. So far no one has told me that my conclusions there would be incorrect, but of course these represent just my personal interpretation and you should treat them as any piece of text you discover from a random blog in the Internet 😉