Dataverse sharing and security errors

Dataverse security combines several layers — security roles, business unit hierarchy, ownership, teams, and explicit record sharing — and an access denial can originate in any of them. The generic "you do not have access" message doesn't say which layer is responsible, which is why diagnosing these reports takes a systematic check rather than a guess.

"You do not have access to [Entity Name]. Ask your system administrator..."

Symptom. A user can't open a specific record type at all, not just a specific record.

Cause. No assigned security role grants any access level (even Organization-level read) on that table for this user.

Fix. Check the user's assigned security roles' privileges for the specific entity and add the missing privilege at an appropriate access level to an existing or new role.

Fix (continued). If the user should have access through a team rather than a direct role assignment, confirm they're actually a member of the team the role is assigned to — a common gap after someone changes teams internally but the team membership isn't updated.

Prevention. Model security roles around job function, not individual users, and review role assignments during any internal team change (a promotion, a department move) as a standard offboarding/onboarding step.

A user can see some records of a type but not others (record-level denial)

Symptom. The user has some access to a table (they can open certain records) but a specific record shows "you do not have access."

Cause. This is almost always the business unit and ownership hierarchy at work: a security role's access level (User, Business Unit, Parent: Child Business Units, or Organization) limits which specific records within a table a user can see, based on who owns the record and which business unit that owner belongs to.

Fix. Check the record's owner and that owner's business unit against the requesting user's own business unit and their role's access level. If the record genuinely needs to be visible outside the normal hierarchy, use explicit record sharing rather than widening the role's access level for everyone.

Prevention. Design the business unit hierarchy and default access levels deliberately during implementation — retrofitting a business unit structure onto live data with existing security roles is a much larger project than getting it right the first time.

Shared record access disappears unexpectedly

Symptom. A user who previously had access to a specific record via explicit sharing loses that access with no visible change to their security role.

Cause. Record sharing can be revoked explicitly, but it's also automatically cleared in some scenarios — a record's owner changing, or a bulk security operation reassigning ownership — and sharing is inherently per-record, so a batch process touching many records can silently drop shares nobody remembers granting individually.

Fix. Re-share the specific record if the access is still needed, and consider whether a security-role or team-based access model would be more durable than per-record sharing for this scenario going forward.

Prevention. Reserve explicit record sharing for genuine one-off exceptions; if a whole group of people consistently needs access to a whole class of records, that's a security-role or team-ownership design question, not a sharing one — sharing doesn't scale and doesn't survive bulk operations reliably.

Field-level security blocking a field the user can otherwise see

Symptom. A user can open a record but a specific field shows as blank or locked, distinct from the rest of the record being fully visible and editable.

Cause. A field security profile restricts that specific field independently of the table-level security role — this is a separate, additive layer specifically for sensitive fields (salary, national ID numbers, and similar).

Fix. Check whether the user is a member of a field security profile granting access to that field, and add them if the access is legitimately needed.

Prevention. Keep the list of field-security-profile members reviewed alongside regular access reviews — a profile is easy to set up once and then forgotten, so membership drifts out of date with who should actually see the field.

Where to go next

The full security model is covered in the Dataverse security model, with field-level security, hierarchical security, and owner teams vs access teams each going deeper on one layer.