Restricted tables and the Power Apps licence boundary

What it does

Restricted tables are the Dataverse tables tied to Dynamics 365 applications where create, update and delete require a Dynamics 365 licence. A Power Apps or Power Automate licence gets you read access to all of them, and nothing more, apart from a couple of named exceptions.

Key facts

The rule is simple and worth memorising: read on a restricted table needs only a Power Apps or Power Automate licence; create, update or delete needs the corresponding Dynamics 365 licence.
Restricted tables span Sales, Customer Service, Field Service, Project Service Automation and Marketing. Examples Microsoft names include Goal (Sales), Case, Entitlement, SLA and Knowledge Article (Customer Service), Work Order and Booking Journal (Field Service), Project Task and Resource Assignment (PSA), and Journey (Marketing).
For the Sales-side restricted table Goal (goal), the entitlement listed is Dynamics 365 for Sales Professional, Dynamics 365 for Sales Enterprise, a Dynamics 365 Customer Engagement plan, or a Dynamics 365 plan.
The Case exception: a Power Apps, Power Automate or Copilot Studio licensed user may create cases and read, update and delete cases they created themselves. They may not manage, route, assign or resolve cases raised by anyone else.
The Work Order exception: Power Apps and Power Pages licensed users may create, read, update and delete work orders for self-reporting scenarios only — an employee logging a facilities issue, for instance. They cannot complete or close work orders or act as a service agent.
Dynamics 365 licences also cover the advanced logic and product-specific configuration management that sits on top of these tables; Power Apps licences do not.
Restriction is a licensing construct, not a platform permission. Dataverse will happily let an under-licensed user write to a restricted table if the security role permits it.
Account, Contact, Lead, Opportunity, Quote, Order and Invoice are not on the restricted list. That surprises people, and it is the reason a lot of Power Apps-licensed builds on Dataverse are legitimate.
The restricted table list changes as Microsoft ships new first-party tables. Check the current page rather than a copy from a previous project.

When to use / skip

This matters on any project where the client wants a Power Apps front end over the same Dataverse environment as Sales — a portal-adjacent internal app, a field data capture app, a Power Automate integration writing back into CRM. The question that decides the design is always the same: which tables does it write to?

If your app or flow only touches Account, Contact, Lead and Opportunity, a Power Apps per-user or per-app licence is defensible and you can build it. The moment it writes to Goal, or to a Customer Service or Field Service table, you are into Dynamics 365 licence territory for every user of that app, and the cost model changes completely.

Where it bites hardest is service accounts and integrations. A Power Automate flow running under an application user still consumes an entitlement, and multiplexing — a small number of licensed accounts fronting a large number of unlicensed users — is not a way around this. If the humans behind the integration are creating restricted-table records, the humans need licensing.

Skip the analysis only when the client has full Sales Enterprise for everyone touching the environment, in which case none of this constrains you.

Configuration decisions

Table-by-table write analysis for every Power Apps app and Power Automate flow in scope. Do it once, properly, and record it.
Whether restricted-table writes get pushed into a Sales-licensed app rather than a Power Apps one, to keep the cheap licence viable elsewhere.
Whether the Case or Work Order self-service exceptions actually fit the requirement, or whether the client's scenario quietly exceeds them.
How integration accounts are licensed and which tables they write to — this is the decision most often skipped.
Whether to enforce the boundary through security roles rather than trusting design intent, so an under-licensed user cannot write even if a future app change tries to.
Whether the client's compliance appetite tolerates a design that is technically possible but licensing-marginal. Some do; get it in writing.

Gotchas

Dataverse does not block the write. There is no error, no warning and no telemetry telling the client they are non-compliant — you find out at true-up.
Read-only access to restricted tables genuinely is free with Power Apps. Consultants routinely over-license reporting and lookup scenarios that never needed a Sales licence.
The Case exception is narrower than it sounds. "Create your own and manage your own" does not extend to resolving, and a self-service ticketing app that lets users close their own cases is outside it.
Multiplexing through an integration account does not change the entitlement position. Microsoft's licensing terms look at the human, not the connection.
The restricted list is not the same as "tables shipped by a Dynamics 365 app". Plenty of Sales tables aren't restricted, and assuming they all are leads to over-buying.
Copying a table list from an older project is a real risk. Microsoft adds tables to this list as new first-party workloads ship.

Consultant notes

Produce a one-page write-access matrix for every non-Sales app in the solution and put it in the design document. It is the artefact that protects both you and the client at audit.
When a client proposes Power Apps licences to save money, agree in principle and then ask which tables the app writes to. The conversation resolves itself.
Don't guess for the client. If the position is marginal, tell them to run it past their licensing specialist or partner account manager, and record that you did.
Check the restricted table page again at design freeze, not just at discovery — it moves.
Before go-live, confirm no Power Automate flow in the solution writes to a restricted table under a service account fronting unlicensed users.

Worth another look when Microsoft adds new first-party tables, or if the Case and Work Order exceptions are revised.