Quick answer. If a model-driven app is proposed over Dynamics 365 seats: as of September 2026, Microsoft’s licensing guide lets Power Apps users access “any Dynamics 365 non-restricted table in the Dataverse”, but writing to Case and other restricted tables needs Dynamics 365 licensing. Check each role’s tables.
The Power Platform team has proposed building the service-case app as a model-driven app on Dataverse, licensed for Power Apps, instead of buying Dynamics 365 Customer Service seats. The proposal says the app uses the same tables. The list no one has written down is which of those tables each role writes to, and that list is what Microsoft’s Restricted tables requiring Dynamics 365 licenses page is read against. This guide sets out Microsoft’s rule, the tables it names for Sales and Customer Service, the exception for cases, and how to decide per app.
Where Microsoft Draws the Line: Restricted Tables
When procurement asks why a Power Apps license is enough, the answer starts with Microsoft’s own sentence. The restricted tables page states that app makers “can use all of the Microsoft Dataverse tables available within Common Data Model to create apps and flows for users who have any version of Power Apps and Power Automate license.” It then narrows that: “a smaller set of tables tied to Dynamics 365 apps (Dynamics 365 Sales, Customer Service, Field Service, Marketing, or Project Service Automation) require canvas and model-driven app users to have a license for the corresponding Dynamics 365 app if they need to create, update, or delete rows within the tables. These are referred to as restricted tables.”
The Dynamics 365 Licensing Guide (September 2026) states the same line from the other side: “Power Apps users who have a Power Apps license may use custom applications to access (that is, create, read, update or delete) any Dynamics 365 non-restricted table in the Dataverse. However, Power Apps users and devices that need to create, update, or delete data in Dynamics 365 restricted tables must be properly licensed for Dynamics 365.”
Microsoft gives two reasons a table is restricted on the same page: “The table is used to store and maintain product-specific configuration data that should typically be not used outside of the application.” and “The table is accompanied by advanced logic that creates and maintains data in a specific way when used within a Dynamics 365 product.” Reading is treated differently: “If an app or flow only reads information from a table, a Dynamics 365 app license isn’t required and an appropriate Power Apps or Power Automate license is all that’s needed.”
Which Sales and Customer Service Tables Are Restricted
If the app is meant to replace a service desk or a sales tracker, check its tables against Microsoft’s list before anything else. The restricted tables page lists, among others, these rows that name a Customer Service or Sales license, quoted by the page’s display name, logical name and license column:
| Table (logical name) | License Microsoft lists for create, update or delete |
|---|---|
| Case (incident) | “Dynamics 365 for Customer Service Professional edition” or “Dynamics 365 for Customer Service Enterprise edition” (or the legacy plans) |
| SLA (sla) | “Dynamics 365 for Customer Service Professional edition” or “Dynamics 365 for Customer Service Enterprise edition” (or the legacy plans) |
| Entitlement (entitlement) | “Dynamics 365 for Customer Service, Enterprise edition” (or the legacy plans) |
| Knowledge article (knowledgearticle) | “Dynamics 365 for Customer Service, Enterprise edition” (or the legacy plans) |
| Routing rule set (routingrule) | “Dynamics 365 for Customer Service, Enterprise edition” (or the legacy plans) |
| Goal (goal) | “Dynamics 365 for Sales Professional” or “Dynamics 365 for Sales, Enterprise edition” (or the legacy plans) |
The legacy plans are the Customer Engagement plan and the Dynamics 365 plan, and the page notes: “Dynamics 365 Customer Engagement Plan and Dynamics 365 Plan licenses are no longer available for purchase”. On the Sales side, Goal is the one row in this list whose license column names a Sales license. For any other table the app writes, apply the non-restricted rule in the Dynamics 365 Licensing Guide to what the restricted list says today, and re-read the list before the design is signed off rather than assuming a table is outside it.
The Case-Table Exception
If the app lets employees or front-line staff log cases for themselves or for customers, Microsoft carves out room for that. Note 1 on the restricted tables page says Power Apps, Power Automate or Copilot Studio licensed users “can ‘create’ cases; can ‘read’, ‘update’ and ‘delete’ self-created cases to enable scenarios including employee self-service and case creation on behalf of customers.”
The same note sets the limit. Those users “can only perform ‘read’ operation on cases created by other users.” It continues: “They can’t ‘update’, ‘resolve’, ‘route’, ‘close’”, and ends: “Users can’t act as a customer service agent, can’t manage cases.” The decision point follows from Microsoft’s words: a user who works other people’s cases is on the Dynamics 365 side of the line, and a user who raises and follows their own cases is not.
What a Power Apps License Covers in a Model-Driven App
If the build option wins on the tables, the next question is what the Power Apps license itself gives. A model-driven app is a Dataverse app by definition: Microsoft’s model-driven app overview says to think of them as “data model driven apps”, because without a data model in Dataverse “you can’t create a model-driven app”. How that choice compares with a canvas app is covered in Canvas vs Model Driven Apps in Regulated Microsoft Environments: How to Make the Architectural Decision That Determines Long-Term Maintainability.
The license is counted per user and, on the per app plan, per app. Microsoft’s Power Platform licensing FAQs state: “Each per app license provides an individual user with rights to one app (canvas and/or model-driven) within a single environment.” Which Power Apps plan fits a given user population is covered in Power Apps Premium vs Per App: What Actually Differs, and Where the Break-Even Sits.
Building the app is project work. From what we can document, quoted at the size we can document it: “Power Apps development work ranges from $50,000 to $350,000 per project, depending on size, complexity and length.”
What a Dynamics 365 License Adds
When the app has to work other people’s cases, SLAs, entitlements, knowledge articles, routing rule sets or goals, the restricted tables page puts those users on the Dynamics 365 license its table names. Appendix E of the Dynamics 365 Licensing Guide opens: “Dynamics 365 licenses provide the right to use custom tables.” It gives Enterprise Applications full users “No limit on number of custom tables”, and gives Sales Professional and Customer Service Professional users the right to “Create and modify up to 15 custom tables (per application) in addition to the included standard tables”.
Power Apps rights inside a Dynamics 365 license depend on the license. The Power Platform Licensing Guide (September 2026) lists those rights in its Power Apps table. For running custom apps, its column for select Dynamics 365 licenses reads “Within same environment as licensed Dynamics 365 application(s)”, and the notes under the table read “Within app context.” and “Dynamics 365 Pro does not have use rights for Power Apps or Power Pages.” Read the table’s column for your license before assuming a Dynamics 365 seat also covers a separate Power App. What Customer Service case management does is described on DYNAMICS 365 CASE MANAGEMENT FOR YOUR COMPANY, and Sales on DYNAMICS 365 SALES MODULE CONSULTING; per-user prices are on How Much Does Dynamics 365 Licensing Cost Per User?
Team Members is a narrower license. The Dynamics 365 Licensing Guide states: “A Dynamics 365 Team Members license holder may customize a maximum of 15 additional tables (custom tables or standard Dataverse tables) that are available to licensed users per the pre-approved scenarios in Appendix E.” What a Team Member can do against a full license is the subject of a separate i3solutions guide, Dynamics 365 Team Member vs Full License: What a Team Member Can Actually Do.
A Front End Does Not Reduce the License Count
If the proposal puts a Power App, a portal or an integration in front of Dynamics 365 to avoid seats, the Dynamics 365 Licensing Guide answers it in one line: “The number of tiers of hardware or software between Dynamics 365 and the ultimate user or devices does not affect the number of licenses required.” The cost side of that rule is covered in The Hidden Costs of a Dynamics 365 Implementation, Beyond Base Licensing.
Design choices after go-live can move the line too. Microsoft’s License requirements for tables page states: “App makers can add code plug-ins and real-time workflows to tables within Dataverse, but doing so could change the license requirements for users of apps already deployed.”
Deciding Per App, in One Table
When you have to defend the choice at a true-up, a table with one row per write pattern holds up better than one answer for the whole app. Every Microsoft statement in the table below is quoted from the restricted tables page or the Dynamics 365 Licensing Guide, as named in each row.
| What the app’s users do | What Microsoft’s documents say | Source | The question to answer |
|---|---|---|---|
| Write only to custom tables and non-restricted standard tables | Power Apps users may access “any Dynamics 365 non-restricted table in the Dataverse” | Dynamics 365 Licensing Guide | Will a later release add a restricted table to the design? |
| Read restricted tables, never write them | “a Dynamics 365 app license isn’t required and an appropriate Power Apps or Power Automate license is all that’s needed” | Restricted tables page | Does any flow or plug-in write to a restricted table on the user’s behalf? |
| Create cases and manage only the cases they created | “can ‘create’ cases; can ‘read’, ‘update’ and ‘delete’ self-created cases” | Restricted tables page, note 1 | Does any user need to work a case someone else created? |
| Work cases, SLAs, entitlements, knowledge articles, routing rule sets or goals created by others | users who “need to create, update, or delete rows” need “a license for the corresponding Dynamics 365 app” | Restricted tables page | Which Dynamics 365 license does the list name for each table they write? |
Where roles fall in different rows, license each role by its own row. The case note on the restricted tables page is written that way: it names “employee self-service and case creation on behalf of customers” as scenarios for Power Apps licensed users, and keeps work on cases created by others for the Dynamics 365 license. Confirm the result with your Microsoft licensing contact before signing.
When the License Question Is the Wrong Frame
If the requirement does not fit either option, choosing a license first solves the wrong problem. In four situations the decision changes shape.
- Take the general question first when configuration cannot express the requirement. Whether to build custom code on Microsoft platforms or configure a packaged product is covered in Custom Microsoft Application Development for Regulated Enterprises: What to Look for in a Senior US-Based Partner.
- Plan for where the workload is going, not where it starts. A case app that will need routing, SLAs and entitlements will cross the line on Microsoft’s restricted list later; price that crossing before building the first release.
- Stop at the read rule when users only look. The restricted tables page states that for an app that “only reads information from a table, a Dynamics 365 app license isn’t required”.
- Settle the estate first when Sales or Customer Service still runs on premises. For that estate, from what we can document: “i3solutions migrates on-premises Dynamics CRM to Dynamics 365 in the cloud and upgrades on-premises Dynamics instances, as project work, with embedded specialists available where your team needs them.”
How i3solutions Answers the Question
When a proposal reaches the approval stage, the useful output is a table list per role that procurement and a Microsoft true-up can both read. i3solutions implements the Microsoft technology a customer needs, Dynamics 365 and other ERP and CRM work included, so either answer, the model-driven app or the Dynamics 365 configuration, is work i3solutions carries. These are the statements we can document that bear on it, quoted at the size we can document them:
- i3solutions implements Power Platform licensing across Power Apps per-app and per-user plans, Power Automate per-flow and per-user plans, and the Microsoft 365 default entitlements where app complexity is low.
- i3solutions selects Dataverse over SharePoint as the primary relational store when a client needs scalable high-volume transactional data, and holds application secrets in Azure Key Vault.
Both options on this page sit on Dataverse: the Dynamics 365 Licensing Guide states that “Dynamics 365 applications use Dataverse capacity and features to store and secure data.” Power Apps come in two kinds, canvas and model-driven, and on the Power Apps side the register attests: “i3solutions builds both kinds through its power platform development services in regulated environments, and the choice always starts with the same question: what is the data and what governance does this app need to inherit.” The sequence is to list the tables each role writes, test the design against Microsoft’s restricted list, and then build either the model-driven app or the Dynamics 365 configuration. Dynamics 365 work is described on Enterprise Dynamics 365 Development Services That Align CRM and ERP to How You Operate.
Key Takeaways
- If users write to restricted tables, Microsoft’s restricted tables page requires “a license for the corresponding Dynamics 365 app”; the Dynamics 365 Licensing Guide lets Power Apps users access “any Dynamics 365 non-restricted table in the Dataverse”.
- Case, SLA, Entitlement, Knowledge article, Routing rule set and Goal are on Microsoft’s list with a Customer Service or Sales license named against them.
- Power Apps users “can ‘create’ cases” and manage their own, but “can only perform ‘read’ operation on cases created by other users”, per the case note.
- A front end does not reduce the count: the licensing guide says the tiers between Dynamics 365 and the user do “not affect the number of licenses required.”
- Decide per role and per table, and re-read Microsoft’s list before the design is signed off.
Frequently Asked Questions
Which Dataverse tables require a Dynamics 365 license?
If users create, update or delete rows in a restricted table, they need the Dynamics 365 license Microsoft names for it. The restricted tables page lists them; for Customer Service they include Case, SLA, Entitlement, Knowledge article and Routing rule set, and for Sales the list names Goal. The page says a Dynamics 365 license is required “if they need to create, update, or delete rows within the tables.”
Can Power Apps users create and update cases?
If users log and follow their own cases, yes; for cases someone else created, no. The case note on Microsoft’s restricted tables page says these users “can ‘create’ cases; can ‘read’, ‘update’ and ‘delete’ self-created cases”, and that they “can only perform ‘read’ operation on cases created by other users.”
Can we use a model-driven Power App instead of Dynamics 365 Customer Service?
If the users only write to custom and non-restricted tables and only manage cases they created, the Dynamics 365 Licensing Guide and the restricted tables page allow it on Power Apps licenses. If they work cases, SLAs, entitlements, knowledge articles or routing rule sets created by others, the restricted tables page requires the Customer Service license it names; the page’s case note says Power Apps users “can’t act as a customer service agent, can’t manage cases.”
Does a Dynamics 365 license include Power Apps?
If you are counting on a Dynamics 365 seat to cover a Power App, check the license first. Microsoft’s Power Platform Licensing Guide lists the Power Apps rights of select Dynamics 365 licenses in its Power Apps table, where the entry for running custom apps reads “Within same environment as licensed Dynamics 365 application(s)”, and notes: “Dynamics 365 Pro does not have use rights for Power Apps or Power Pages.” Read that table for your license before assuming a Dynamics 365 seat covers a separate Power App.
Does reading Dynamics 365 data from a Power App need a Dynamics 365 license?
If the app only reads, no. Microsoft’s restricted tables page states: “If an app or flow only reads information from a table, a Dynamics 365 app license isn’t required and an appropriate Power Apps or Power Automate license is all that’s needed.”
List the Tables Each Role Writes Before Anyone Buys a License
Bring the proposal you have, even a draft: the roles, what each one does in the app, and the tables the design touches. The conversation turns it into one row per role against Microsoft’s restricted list, and keeping the design where it is can be one of the answers it reaches. Talk to a senior architect
Sources
- Microsoft Learn, Restricted tables requiring Dynamics 365 licenses, read 26 September 2026.
- Microsoft, Dynamics 365 Licensing Guide, read 26 September 2026.
- Microsoft, Power Platform Licensing Guide, read 26 September 2026.
- Microsoft Learn, Overview of building a model-driven app with Power Apps, read 26 September 2026.
- Microsoft Learn, Power Platform licensing FAQs, read 26 September 2026.
- Microsoft Learn, License requirements for tables, read 26 September 2026. Microsoft revises its restricted list and licensing guides; check the current versions before committing a design.
