When a Dataverse project goes into turmoil after go-live, in most cases it's about permissions. Either someone sees something they shouldn't — the rarer but more delicate case. Or, far more often, someone doesn't see something they urgently need, and nobody on the team can explain why.
Dataverse's security model is powerful, but it has a steep learning curve, because several concepts take effect at once and their logic isn't intuitive. This post explains the model so you set it up correctly before go-live — instead of repairing it afterward under pressure. The overall context is in the Dataverse guide; here it's only about security.
The model consists of four concepts that interlock. You have to think about all four together — looked at individually, each one leads you astray.
The decisive and most overlooked point: permissions are additive. If a user has multiple roles, the more generous setting applies per privilege. There is no "deny wins." A restrictive role has no effect if a second, loosely configured role opens the same right further. Whoever hasn't internalized this builds role chaos and wonders why the "narrow" role limits nothing.
The following diagram shows which layers a read request passes through and where "additive" concretely kicks in.
This single diagram explains the majority of the "why does this person see that?" tickets after go-live. It's almost never a platform fault — almost always a second role that quietly opens everything back up.
Every record in a standard table has an owner — a user or a team. The access level "own" refers exactly to that: if a user sees only "own" records, they see those they own (or the team they belong to).
From this follows a design decision that has to be made early: owner team or sharing? If a record should be visible to a group, there are two ways. Owner teams are clean and scale — the record belongs to the team, all team members see it through their normal access level. Manual per-record sharing also works, but scales miserably and becomes, in environments that have grown over time, an unmaintainable layer nobody can trace anymore. The practical rule: model group visibility via owner teams, use sharing only for genuine one-off exceptions.
Sometimes a user should see a record — but not a particular field within it (salary, margin, a sensitive note). For that there is column/field-level security: a single field is secured and only released via a field security profile.
This works cleanly but costs clarity. Every secured field is an additional management axis alongside the roles. Our practical recommendation: use it sparingly, only for genuinely sensitive fields, and document which profile opens which field. Whoever sprinkles field-level security broadly builds a model that is formally correct and practically no longer maintainable.
Distilled from security remediations, by frequency:
Striking, as with data modeling: none of these mistakes is a platform fault. They're discipline and design faults — and all of them are almost free to avoid at the start. How closely security and the data model are connected shows especially in the question of whether a concept gets its own table — covered in detail in our data modeling best practices. And whether Dataverse is even the right tool for your case is clarified by our comparison Dataverse vs. SQL vs. SharePoint — precisely because a row-level security model is often the actual argument for Dataverse.
When you build a security model from the ground up, in this order:
The following diagram shows this order as a staircase — each step builds on the previous one, and the most expensive correction sits right at the bottom.
Step six is the one most often left out — and the one that would have prevented the most post-go-live tickets.
The Dataverse security model isn't complicated because the platform is bad — it's complicated because security is complicated. Four building blocks, additive logic, no "deny": whoever internalizes these three truths builds a model that holds. Whoever skips them builds one that explodes in the ticket system after go-live.
The most honest recommendation: a few task-related roles, owner teams instead of sharing, and test every role with a real test user before anyone depends on it in production. Trust lost after go-live because someone saw the wrong thing isn't won back with a correction role.
We design your security model along the real visibility boundaries — or review an existing one honestly and find the spot where the "narrow" role is quietly undermined. Before it becomes a data-protection issue.
