Light-touch users: restricted tables, Team Members and Power Apps licences

What it does

Field Service's core tables are restricted tables in Dataverse: reading them is fine with a Power Apps or Power Automate licence, but creating, updating or deleting records in them requires a Dynamics 365 Field Service licence. This is the mechanism that decides which of your peripheral users you actually have to pay Dynamics money for.

Key facts

The rule is read versus write. Read access to restricted tables needs no Dynamics 365 licence. Create, update and delete do.
Restricted Field Service tables include msdyn_workorder, msdyn_workorderservicetask, msdyn_workorderproduct, msdyn_workorderservice, msdyn_agreement and its booking and invoice setup tables, msdyn_customerasset, the purchase order and RMA/RTV families, msdyn_inventoryjournal, msdyn_productinventory, msdyn_fieldservicesetting, msdyn_scheduleboardsetting, msdyn_schedulingparameter, plus BookableResource, BookableResourceBooking and msdyn_timeoffrequest.
Bookings are restricted. That's the one people miss — a Power Apps-licensed user cannot create or move a booking, which rules out most home-grown scheduling front ends.
There is a documented exception for self-service: a user self-reporting an issue (Microsoft's example is an employee logging a facilities problem) may create, read, update and delete their own work orders under a Power Apps or Power Pages licence. Completing work orders, or acting as a technician, is not covered.
Restricted APIs include msdyn_SearchResourceAvailability, msdyn_SearchResourceAvailabilityForRequirementGroup, msdyn_CreateRequirementGroupBooking, msdyn_CascadeBookingChanges and msdyn_SelectNotToExceed. Custom controls such as the schedule board, booking card, work order list and the inspection survey creator are likewise restricted.
Team Members is a named-user licence for light consumption. Its experience is delivered through three designated apps: Customer Service Team Member, Sales Team Member and Project Resource Hub. There is no Field Service Team Member app.
Team Member apps are capped at 15 tables of customisation, and Team Member users cannot open custom model-driven apps, the Sales Hub or the Customer Service Hub. The error reads "Invalid License: This app requires a license and you don't have the appropriate license to access this app". Administrators, customisers and makers are exempt from that enforcement.
Power Platform admin centre carries a Team Member Conformance Report under Dataverse analytics, which is the only practical way to see whether Team Member usage matches the entitlement.
Solution checker has three Field Service licence rules: meta-license-fieldservice-sdkmessages, meta-license-fieldservice-entity-operations and meta-license-fieldservice-customcontrols. The checker is not licence-aware — it flags components that require a licence, it does not know what your tenant owns.

When to use / skip

Reach for this when somebody asks the inevitable question: "can we just build a Power App for the warehouse team / the call handlers / the account managers instead of buying Field Service licences?" The honest answer is usually partly. Read-only dashboards, status lookups and reporting front ends are entirely legitimate on a Power Apps licence, and you should build them that way rather than buying Dynamics licences for people who never write.

Anything that creates a work order on a customer's behalf, moves a booking, closes a task, adjusts inventory or touches an agreement is a Field Service licence. No amount of canvas app cleverness changes that, and the enforcement is at the platform, not at the UI.

Team Members is rarely the answer on a field deployment. With no Field Service Team Member app, the entitlement doesn't line up with anything a field organisation needs, and the temptation to point Team Member users at a custom app runs straight into app-level enforcement.

Configuration decisions

Which peripheral personas are genuinely read-only, and whether you can hold that line for the life of the system.
Whether customer- or employee-facing intake goes through Power Pages under the self-service exception, or through a licensed internal user creating the work order.
Whether reporting goes via Power BI over the Dataverse data — which sidesteps the app-licence argument entirely — or via a model-driven app.
Whether solution checker's licence rules run in your build pipeline, and who is expected to interpret the warnings.
How you evidence entitlement at audit time: which report, run by whom, how often.

Gotchas

Scheduling is the trap. Bookable Resource and Bookable Resource Booking are both restricted, so a "lightweight dispatcher app" is not a lightweight licence.
The self-service work order exception is narrow and reads narrowly. Stretching it to cover technicians completing jobs is the single most common licensing overreach on Field Service projects.
Solution checker warnings look like defects to a developer. They are not — they say a component needs a Dynamics licence, nothing more. Teams strip perfectly good Field Service functionality out of solutions because nobody explained that.
Team Member enforcement bites at app level, not privilege level, so a Team Member user with generous security roles will still be blocked from the app while appearing over-privileged in a role review.
Admins, customisers and makers are exempt from Team Member enforcement, which means your test with an admin account proves nothing about what a real user will see.
Read access being unrestricted is a licensing statement, not a security statement. Security roles and column-level security still decide what anyone sees.

Consultant notes

Get the client's licensing position written down before design, not after. "We'll use Power Apps for that team" is a design assumption with a price tag attached.
When you push back on a custom scheduling front end, do it on the restricted-table list rather than on opinion. Naming BookableResourceBooking ends the conversation quickly.
Demo the actual failure to the client's architect: a Power Apps-licensed user reading a work order fine and failing on save. It lands better than a table in a slide.
Before go-live, run solution checker over the shipped solutions and keep the output. It's a decent artefact to hand the client for their own compliance file.
Detail beyond the read/write rule — exact use rights per SKU — lives in the Dynamics 365 Licensing Guide. Say so rather than guessing.

Worth another look if Microsoft adds a Field Service Team Member app, or widens the self-service work order exception.