Almanac
Microsoft/d365csDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Customer Service: implementation notes, gotchas, and configuration decisions beyond the official docs — across case management, queues and routing, knowledge base, SLAs, omnichannel, agent experience, Copilot, analytics, and administration.

d365cs/10-licensing/feature-licensing-team-members-restrictions.md
feature-licensing-team-members-restrictions.mdv1 · history
CurrentApplies to AllUpdated 6 days agoSource Microsoft Learn ↗

What it does

Team Members is the cheap seat for people who consume data and log the occasional request but never work a queue. In Customer Service it grants access to exactly one app — Customer Service Team Member — and its boundaries are enforced by app access rules on one side and Dataverse restricted tables on the other.

Key facts

  • A Team Members licence gives access to three designated apps only: Customer Service Team Member, Sales Team Member, and Project Resource Hub. Attempting to open Customer Service Hub or Copilot Service workspace returns an invalid licence error naming the required service plan.
  • Each Team Member app is capped at 15 tables. Those can be Dataverse core tables, Microsoft-published tables or custom ones, and additional tables reached through subgrids, dashboards and lookups sit outside that count.
  • Reading is not restricted. A Team Member can read Dynamics 365 data broadly; the limits are on what the app exposes and what they can write.
  • Enforcement happens at app usage, not at customisation time, and admins, customisers and makers are exempt from it. Testing with your own account proves nothing.
  • Enforcement does not apply to the legacy web client. Any surviving classic UI is an enforcement hole.
  • The Customer Service Team Member app is installed manually from the Power Platform admin center under Resources > Dynamics 365 apps, and users need the Customer Service Team Member security role.
  • In that app the Customer field on a case is read-only and auto-mapped to a default account, which admins set through the Customer Service Team Member solution. Sending knowledge article URLs is not supported.
  • Restricted tables sit underneath all of this. Create, update and delete on Case (incident) and SLA (sla) need Customer Service Professional or Enterprise; Entitlement (entitlement), Knowledge Article (knowledgearticle) and Routing Rule Set (routingrule) need Enterprise. Read on any of them needs only a standard Power Apps or Power Automate licence.
  • The Case table carries a documented carve-out: a Power Apps or Power Automate licensed user may create cases and manage only the cases they created themselves.
  • Compliance is monitored after the fact through the Team Member Conformance Report and Non-conformant Usage Report, under Dataverse Analytics in the Power Platform admin center.
  • Not supported on Dynamics 365 Customer Engagement (on-premises).

When to use / skip

Team Members is the right seat for the internal requester population — the several thousand staff who raise an IT or HR ticket twice a year, add a note, attach a screenshot and close it. Licensing that group as agents is the single most common overspend in a service deployment, and Team Members exists precisely to stop it.

It is the wrong seat for anyone who resolves work. A Team Member cannot pick up somebody else's case in the designated app, cannot send a knowledge article link, and cannot own the customer relationship on the record. Every project that tries to stretch Team Members into a "light agent" tier ends up either non-compliant or rebuilding on a Power Apps per-app plan.

If the requester experience needs more than the designated app offers, stop stretching the licence and price a Power Apps per-app plan or a Power Pages site against it. Both are legitimate answers and both are cheaper than a compliance conversation.

Configuration decisions

  • Which 15 tables the Team Member app exposes, and what falls outside them.
  • The default account the Customer field maps to, and whether that model survives contact with a multi-company or multi-brand client.
  • Whether the internal requester journey belongs in the Team Member app at all, versus a Power Pages portal or a Teams-fronted experience.
  • Which security role combination the Team Member population gets, given the app role is only part of the picture.
  • Who reviews the conformance reports and on what cadence, since nothing surfaces breaches automatically.
  • Whether any Power Automate flow or integration runs under a Team Member identity and writes to a restricted table.

Gotchas

  • The read-only Customer field mapped to a fixed default account catches out almost every implementation with more than one legal entity. It is configured in the solution, not the UI, and nobody finds it during a demo.
  • Not being able to send knowledge article URLs is a small limitation that reliably breaks a designed process, because sharing an article is the obvious thing a light user wants to do.
  • Maker and admin exemption means your build and test cycle never trips the enforcement. Provision a genuinely Team Member licensed test user or you will find out in production.
  • Restricted-table write failures look like a security role problem. People spend days in role editors before anyone checks what licence the running identity holds.
  • Conformance reports are retrospective. By the time non-conformant usage shows up, it has been happening for weeks and the client has budgeted as if it were compliant.
  • Any remaining legacy web client access sidesteps enforcement entirely, which is a licence exposure rather than a feature.

Consultant notes

  • Do the licence mix arithmetic early: agents on Enterprise or Premium, internal requesters on Team Members, everyone else on nothing. Get the client to sign off the counts before design, because they drive the whole commercial case.
  • Always keep one Team Member licensed test account in every environment and make it part of the UAT script. It is the only reliable way to see what that population sees.
  • Demo the Team Member app to the client's IT and HR leads specifically. They are the ones whose staff will use it and the ones who will ask for the one feature it does not have.
  • Push back on "light agent" requirements. Ask what the person actually does; if the answer includes touching someone else's case, they need a full seat.
  • Before go-live, pull the Non-conformant Usage Report once as a baseline and hand the client a note on who reviews it and when.

Worth another look after the next release wave, or if the designated Team Member apps or the restricted tables list change.

Was this accurate?
Related
Customer Service Professional versus Enterprise10-licensingRecord ownership, sharing and access teams09-administrationCopilot access, privileges and data controls07-copilot-in-customer-serviceProvisioning service users and their profiles09-administrationDataverse capacity and add-ons for a service tenant10-licensingAuditing a Customer Service deployment09-administration