Onboarding users to Dataverse without the “I can't see anything” tickets

Most day-one access problems in model-driven apps trace back to a few design decisions made early. Here's how I set up roles, business units and teams so new users land ready to work.

The first week after go-live has a pattern. The app works in testing. Then real users sign in, and the tickets start: “The app isn't in my list.” “I can see the form but the save button is gone.” “Why can I see my manager's cases?”

Almost none of these are bugs. Each one traces back to a security design gap that testing with admin accounts never exposed. Dataverse security is powerful and predictable once you understand its layers. The work is in planning them before the first user arrives.

1. Start with a role matrix, not the role editor

Before opening the security role editor, I build a simple matrix in a spreadsheet. Personas down the side, tables across the top, and in each cell the privileges (Create, Read, Write, Delete, Append, Append To, Assign, Share) and access level that persona needs.

Access levels are where most of the thinking happens. Dataverse gives you five:

The matrix becomes the spec. Business owners can review it without learning the role editor, and it doubles as the audit document later.

2. Build layered roles instead of one big role per persona

A single role per persona looks tidy until you have twelve of them that are 90% identical. Every new table then means twelve edits.

I use layers instead:

• A base role that every user of the app gets. It grants the app itself, Read on shared reference tables, and the core privileges the platform needs. I copy it from the out-of-the-box Basic User role rather than editing Basic User directly, so platform updates don't collide with my changes.
• Function roles that add what a specific job needs, such as “Case Worker” or “Approver.”
• Elevation roles for the small group that needs broader access, such as “Department Lead.”

Dataverse combines privileges across all of a user's roles and grants the highest access level from any of them. That makes layering safe: adding a role can only widen access, never narrow it. It also means you can't use a role to take something away, so keep the base role minimal.

3. Put the business unit decision first

Business units drive record visibility, so choose the structure before you assign anyone. Keep it as flat as the organization allows. A deep hierarchy built to mirror an org chart becomes painful the first time someone changes departments.

That move is worth knowing about in advance. By default, when you change a user's business unit, Dataverse removes all of their security roles. The user signs in the next morning and has no access at all. If your environment uses record ownership across business units, the DoNotRemoveRolesOnChangeBusinessUnit environment setting can keep roles in place. Otherwise, put “reassign roles” on the transfer checklist.

4. Assign roles to Entra ID group teams, not individuals

Assigning roles user by user works for ten people and falls apart at fifty. Microsoft Entra ID group teams fix this. You create a Dataverse team linked to an Entra security group, assign roles to the team, and membership follows the group.

• Membership is added and removed as users access the environment, based on their current Entra group membership. Onboarding becomes “add them to the group.”
• Offboarding follows the same path, which matters more than people expect.
• Group members are managed in Entra ID, not in the Power Platform admin center, so agree with your identity team on who owns each group.
• Watch the team role's member's privilege inheritance setting. It decides whether members get the privileges as themselves or only through the team, which changes what they can do with records they own personally.

I also recommend a security group on the environment itself. It limits who can be added to the environment at all, which keeps licensed users from other departments from appearing in it.

5. Don't forget app access and column security

Two gaps catch almost every team at least once.

The app isn't in the list. A model-driven app is shared by associating it with security roles. If none of the user's roles is associated with the app, they won't see it, even if they have every table privilege. When I add a new function role, I add it to the app's roles in the same sitting.

A field is blank or read-only. Column security profiles control access to sensitive columns separately from table privileges. A user can have full Write on a table and still see a secured column as empty. Assign column security profiles to teams, just like roles, and include them in the role matrix.

6. Test as each persona before go-live

Testing with an admin or System Customizer account proves the app works. It proves nothing about access.

1. Create one test user per persona, licensed and in the right business unit and Entra groups.
2. Write a short script per persona: open the app, find a record, create one, edit one, attempt something they shouldn't be able to do.
3. Check the negative cases as carefully as the positive ones. If a user can see a colleague's records, log it as a finding.
4. Re-run the scripts after every solution import that touches roles, since a role in a managed solution can overwrite changes made in the target environment.

A day-one onboarding checklist

• User is licensed and in the environment's security group.
• User is in the correct business unit.
• User is in the Entra groups that map to their persona's teams.
• At least one of their roles is associated with the app.
• Column security profiles are assigned where needed.
• A quick sign-in check: they can open the app and see one of their own records.

When onboarding is a checklist instead of a scramble, the first week after go-live is about how people use the app, which is the conversation you want to be having.