Almanac
Microsoft/dataversePower Platform

Consultant KB for Microsoft Dataverse, the data layer under Dynamics 365 and the Power Platform: data model, security model, business logic, APIs and integration, search and queries, analytics and Fabric, ALM and solutions, administration, governance and compliance, and Dataverse as an agent data platform, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Dataverse release plans, docs repo and product blog, plus the author's own consultant notes.

feature-user-types-in-dataverse.mdv1 · history
CurrentApplies to AdminUpdated 3 weeks agoSource Microsoft Learn ↗

What it does

Explains how users arrive in a Dataverse environment and which types of user record you'll meet: regular synchronised users, agent users, application users, non-interactive users, users without licences, the support user and the delegated administrator. It also covers how profile fields sync from the Microsoft 365 admin center.

Key facts

  • You create the user account in the Microsoft 365 admin center. Once a licence is assigned the user is also created in the environment, and the sync can take a few minutes.
  • A synchronised user can't use customer engagement apps until a security role is assigned, directly or through a group team.
  • Agent users (preview) have Microsoft Entra Agent ID identities and are added to the environment to give them data access.
  • Application users are identified by the ApplicationId attribute on the system user record.
  • Non-interactive users skip licence-based provisioning rules (security group rules still apply), can't use the Dataverse web interface or admin portals, only reach Dataverse through SDK or API calls, and are capped at seven per environment.
  • Users without licences (preview) are Entra users with no Dynamics 365 or Power Apps licence. They're created disabled when added to an activity's To, Cc or Bcc line, can't sign in to Dataverse web apps or admin portals, and become regular users if licensed. Admins can't create them by hand, and an environment feature, Activities for users without licenses, has to be enabled.
  • The support user (UPN [email protected], access mode 3) and the delegated administrator ([email protected], access mode 5) are placeholder records that Dataverse maps all Microsoft support users and delegated partner admins onto at runtime. Neither syncs with Entra.
  • Profile sync covers names, title, phones, address and the Entra object ID. Full Name and Primary Email aren't auto-updated, Internal Email Address stops syncing once you edit it, custom fields never sync, and a blank First Name becomes "#".

When to use / skip

Use it when you're designing integration identities, auditing why a user can't get in, or explaining to a client why a support person shows up as a strange UPN in the audit trail.

Skip it for security role design. The roles, business units and teams docs cover what users can actually do.

Configuration decisions

  • Integration identity. Decide application user versus non-interactive user, bearing the seven-user cap in mind.
  • Access for unlicensed senders. Decide whether the activities-for-unlicensed-users preview is wanted before turning it on.
  • Role assignment route. Group teams are easier to govern than direct assignment, particularly with large tenants.

Gotchas

  • A licensed user with no security role still can't do anything. It looks like a sync failure and isn't.
  • Editing Primary Email or Internal Email Address in the environment can quietly stop the field following Entra changes.
  • Non-interactive users hit the cap of seven faster than expected when every integration gets its own.
  • The delegated admin and support records appear in audit logs under placeholder identities, which can alarm a security reviewer.

Consultant notes

  • Inventory application and non-interactive users at handover. They accumulate with each project and nobody knows which ones are live.
  • If sync seems stuck, sign out of the app and the admin center, close the browsers, and sign back in. It's dull but it works.
  • Tell the security team up front about the placeholder support identities, and have them agree the audit wording before the first review.
  • Treat the preview user types as non-production until they reach GA; the behaviour around disabled status and conversion may move.

User types are being extended for agent identities — worth revisiting when agent users reach general availability.

Was this accurate?