RBAC in Dataverse is often misunderstood.
Not because it is complicated, but because it is usually explained through roles and UI settings – instead of real access behavior.
Many solutions look secure.
Users see only “their” records. Buttons are hidden. Views are filtered.
From a compliance perspective, this feels reassuring.
Until it isn’t.
In this session, we will look at how access control in Dataverse behaves when solutions move beyond demos and into real, multi-user scenarios. We will explore why UI-based access logic creates false confidence, how it breaks under collaboration requirements, and why this gap often turns into a compliance issue rather than a functional bug.
Using practical, demo-driven examples, we will focus on Owner Teams and Access Teams as the mechanisms Dataverse provides to model access correctly:
-
✅ when records should be owned by teams rather than individuals
-
✅ how to manage dynamic, record-level access without manual sharing
-
✅ how access changes automatically as users join or leave a team
You will learn:
-
what RBAC in Dataverse actually enforces
-
why UI logic does not satisfy compliance expectations
-
how Owner Teams and Access Teams reduce over-permissioning
-
how to design access models that remain defensible during audits
No deep security theory.
No “checkbox compliance”.
Just practical access patterns that hold up when someone finally asks, “Who can see this data – and why?”
(And yes, RBAC sometimes stands for Really Bad Access Control – especially during audits)
