Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What protects your data and Dataverse? Dataverse doesn't protect your business data with a password or a firewall. It protects that data with a security role, which sounds like a small admin setting until you realize it decides what every person in your company can see, change, and even print. One role can reach a single person's own records or every record in the whole environment. And the difference comes down to a choice most people never notice. You might think that's only an admin problem, but it's the thing behind every permission error you've ever hit. By the end, you'll read any role name and know what it's actually saying. What Dataverse is. Dataverse is the data layer that sits underneath the power platform, the family of tools that includes power Apps, Power Automate, and Power BI. Think of it as the shared filing cabinet that your apps, your flows, and your reports all reach into that shared cabinet is the point because the rules we set here follow the data into every tool that reads it. Inside the cabinet. Everything lives in tables. A table is a set of rows and columns, which is the same shape as a spreadsheet, except the columns are fixed and every row has to follow the same rules. That structure is what keeps Dataverse consistent. When one hundred different apps read from it and write back to it. Tables also know about each other. A customer row can be linked to the orders that belong to it, and that link holds no matter which app created the record. A plain file can't do that, and it's a big part of why businesses move their data here. The names have changed over the years and that trips people up. Microsoft used to call a table an entity, a column, a field, and a row a record. In November of twenty twenty, they renamed all three to sound more like a normal database. Walk into any forum today and you'll still see the old words, so it helps to know they mean the same thing. You might wonder why anyone bothers when a spreadsheet is sitting right there and it's free. The short answer is that a spreadsheet won't stop someone typing a date into a phone number column, and it doesn't understand that a customer connects to a set of orders. Dataverse enforces those rules at the platform level, so every app inherits the same discipline. Dataverse also isn't only for power apps. Dynamics three hundred sixty five sales, customer service, and human resources keep their data in Dataverse, too. Because of that, the security model you're about to learn follows the data everywhere it goes, and it turns up in products you wouldn't expect. So the cabinet is shared when something is shared, the only question that matters is who gets a key. A security role is a job description for your data. Here is the head fake. A security role looks like a settings screen full of checkboxes, and it's easy to assume it's about which app screens you can open. It isn't about screens at all. Security role is a job description for your data, and it says what a person is allowed to do with the records they can reach mechanically. A role is a bundle of privileges, and you assign that bundle to a user or to a team. The privileges add up. So if someone holds two roles, they get the broadest access from either one. There's no way for one role to take away what another one. Granted, that cumulative rule is the one to tattoo on your brain. Dataverse has no deny rule, so you can only ever widen access. Never narrow it. If one role opens a door, no second role can close it again. The core privileges come in eight pieces, which are create, read, write, delete, append, append two, assign and share, create, read, write and delete are easy to picture. Append lets you attach a record to another one, like adding a note to a customer record. Append to is the other side of that, and it means something else can be attached to your record. Assign hands ownership of a record to someone else and share. Let someone in while you keep your own access. Take a support rep who needs to log calls and update customer notes. Her role lets her create and update contacts and cases so she can work all day. She still can't delete a customer or hand one to another rep because the role never granted those privileges. That's the job description. Doing its work roles also carry privileges that have nothing to do with a single record. Some let a person publish articles or turn on business rules, and some cover private actions, like exporting data to excel or printing it. That's the part beginners miss. The model controls actions, not only records. So a role can decide whether someone is allowed to take data out of the system. So a role tells you what a person can do. It doesn't yet tell you how far that permission reaches. And that second half is where things get interesting. The five access levels and how far a permission reaches every privilege also has an access level, which sets how deep into the structure it reaches. There are five of them, and the names are more intimidating than the ideas. The five are organization, parent child, business unit, business unit, user, and none user is the smallest useful one and it covers your own records. Business unit covers everything your department owns. Parent child business unit covers your department plus the departments underneath it. Organization covers everything in the environment all the way across the company. None means no access at all. Those levels stack upward organization automatically includes every level below it. Parent child business unit includes business unit and user and business unit. Includes user choosing the top level isn't only broad, it's every smaller level rolled into one. A concrete example makes the difference. Click read access at the user level on a contact's table. Let someone read only the contacts they own. Give that same read privilege at the business unit level, and they can read every contact their unit owns. The role is the same, the table is the same, and the outcome is completely different. Because the only thing that changed was one drop down. There's a second example that shows the same point from the other direction. Give someone read at the organization level on that context table, and every contact in the company opens up to them, including the ones owned by divisions they have never worked with. That's how a helpful role quietly becomes a company wide window. Some tables skip the middle levels entirely. A table can be organization owned, which means a privilege on. It covers either the whole organization or nothing at all. You pick that ownership type when you create the table and it stays fixed. None is worth a second look to because it's the only level that says no. Everything else on the list adds access and none is how you spell out the opposite on purpose. That sounds obvious, and it's still the setting. People forget when they wonder why someone can see a table they shouldn't. So reach is the second half of the model, and it only makes sense once you know what a business unit is. A useful habit is to read every role as a pair of settings. The privilege tells you the verb, and the access level tells you the range. Read them together, and the role turns into a handful of plain sentences about what a person can do. Business units. The departments of Dataverse. Every Dataverse database starts with one root business unit, and you can create child business units under it to split people and data into smaller boundaries. Every user in an environment belongs to a business unit, and by default, the records they create are owned by that unit. The cleanest way to hold this is to pair the two ideas. The business unit is the department and the security role is the job description. A role only means something inside the unit it was granted from, which is why two people with the exact same role name can end up with very different access. Picture two divisions under one root. Someone in Division A opens a contact and sees the Division A contacts they own. Someone in Division B can't see those at all because they belong to a different unit. Each person still has a role and the role still does its job, but the unit decides where the job applies. There's a limit worth knowing early a tables ownership type is set the moment the table is created, and you can't change it later. If you build a table as organization owned and later realize you needed per department control, there's no switch to flip. That's one of those early decisions that gets expensive. Microsoft has also modernized business units, turn on record ownership across business units, and a person can hold roles from more than one unit and own records in any of them. That removes the need for a separate role from every unit they touch. In a small company, you might never create a second business unit at all. Everyone sits in the root unit and the roles carry the whole load. The structure only starts to matter once departments genuinely need to be walled off from each other. That's why the hierarchy earns its keep. Creating a business unit for every team sounds tidy, and each one adds users, teams and records to look after. A deep tree gets hard to reason about. Fast and roles are the lighter tool for most of the work. All of that works person by person, which stops scaling the moment your company grows. That's what teams are for teams giving access to groups instead of people and own a team owns records and can be assigned security roles. So every member picks up the teams privileges. The owner team is the workhorse. Instead of assigning the same role to fifty people, one at a time, you assign it once to the team and access follows. Membership and access team works differently. It doesn't own records, and it doesn't have security roles of its own. Members get access because the record is shared with the team, which makes it a tool for exceptions instead of a foundation. There's a third kind the Microsoft Entra Group team. It behaves like an owner team and can hold security roles, but its membership comes straight from a Microsoft Entra group. When someone joins or leaves that group, their Dataverse access moves with them, and nobody has to remember to update it by hand. Picture a new hire joining the sales team on a Monday. If the sales team holds the sales role, adding her to the team grants everything she needs in one step on her last day. Removing her from the team takes it all back just as cleanly. Compare that with hunting down every role someone assigned her by hand. A team also gives you one place to answer the question that always comes up, which is who can see what you look at, the roles the team holds, and you have your answer. That beats opening fifty user records and hoping you spotted the odd one out. The team is also where you want the access conversation to happen. When someone asks for more, you ask which team they belong to rather than which role they want. Because the team is the thing you can explain and review one caution before you lean on teams too hard. A team can hold several roles at once, and because privileges add up, a team with two overlapping roles hands out the wider of the two. To everyone on it, teams make access easier to manage, and they don't make it narrower by themselves. That's the practical win. The role stays the same, the team carries it and people come and go without anyone rebuilding the permissions. The layers you reach for only when you have to. Teams and roles cover the everyday case and everything past this point is for the exceptions. Start with record sharing. You can share a single record with one person or one team, and it does exactly what it sounds like. Sharing is also the slow path. It's less efficient than a role and harder to troubleshoot later, and sharing with a team beats sharing with each person separately. A shared record is easy to forget, so over time you end up with access scattered across hundreds of records and no clean way to audit it. Next is column level security, which protects a single column rather than a whole record picture a salary column on an employee table. You enable protection on that column and grant it through a column security profile, and only people with the profile can read or change it. Column security doesn't hand anyone the record itself. The person already needs record access before the profile does anything, so it works like a second lock on a door someone can already open. Use it where you need it because leaning on it heavily can slow things down. The last layer is hierarchy security, and it's off by default with the manager hierarchy. Dataverse follows the manager field on each user record, so a manager can see the work of the people who report to them. With the position hierarchy, you define job positions and arrange them in a tree, which lets access across business units when you need it to. Both models use a depth setting to limit how many levels down that read only access reaches one. Detail trips people up here, a manager still needs at least user level read on a table before they can see a reports records. The hierarchy widens what they see and it never creates access. The role didn't already allow. Microsoft also suggests keeping the effective hierarchy to about fifty people or fewer. Under any one manager or position. You use the depth setting to stay inside that number, which is cheaper than building a pile of business units to do the same job where beginners get burned and the honest limits. Start with the habit of adding a roll to fix every problem, because privileges only ever add up. A second roll can quietly open far more than the person needed, and nothing warns you. Read the cumulative rule as a warning instead of a convenience, and give people the smallest roll that does the job. A permission you didn't intend to give is still a permission you gave. Then there's sharing. Treating record sharing as a design works for a handful of exceptions, and it turns into a mess once it becomes your main plan. Every shared record has to be tracked by hand, and every one is a place access can hide. A third mistake is expecting a roll to hide something. If someone already has organization level read on a table, no other role can take that away, and adding a roll won't close the gap. The only way to narrow access is to change the role that granted it in the first place. Copying a big roll is the last trap worth naming because it's faster than building a small one. The system administrator role is tempting since it always works, and handing it out turns an ordinary user into someone who can rewrite the rules themselves. A copy is only safe when you actually trim it down afterward. The error you'll actually run into is this one. One or more commands are unavailable due to your current privileges for this environment. It looks cryptic and it means one plain thing. The role doesn't include the privilege for the action you're trying. And the fix is a role that has it. The message points add privileges for an environment, so it aims you at a role rather than at the app, which narrows the search a lot. Two more limits are worth holding on to. Only a system administrator or someone with a tenant level admin role can assign or change security roles. A tenant level admin role doesn't hand you Dataverse data on its own either, because you still need the system administrator role inside that specific environment. Those two facts explain a lot of confused support tickets. Storage is a limit of a different kind. It comes from licensing rather than any technical ceiling. A default environment starts with three gigabytes of database capacity, three gigabytes of file capacity, and one gigabyte of log capacity. And you add more from there. How Dataverse fits into Microsoft three hundred sixty five Azure and the power platform. Zoom back out and the pieces line up. Environments act as security boundaries so one environment can carry strict rules while another stays open, which is how teams keep a test environment from leaking into production. You can build a tight model in a sandbox, watch it, break a flow, and fix it there. Instead of in the environment your staff use every day, users are authenticated by Microsoft Entra ID, the same identity layer behind Microsoft three hundred sixty five, and licensing is the first gate before any role applies that order matters. A role only decides what someone can do after they're signed in and licensed at all. Microsoft Entra security groups add one more step above the roles. You can use them to control who is allowed into an environment, which means a person can be licensed and still never see the data at all. Dataverse sits under the power platform as its data platform, and the dynamics three hundred sixty five apps keep their records in the same place. Because the permission model lives with the data it travels with it, a canvas app, a model driven app, a flow, and a power BI report all hit the same security wall. That is exactly why the rules were put there instead of inside each app. Azure shows up around the edges with entry ID, handling identity and the storage and scale story sitting behind Dataverse. The takeaway for a beginner is simple this permission model isn't a power app setting. You learn once and forget that model belongs to the data platform, so it follows you into every tool that touches that data. It is also the part where you usually learn the hard way right after someone opens a record they were never meant to see. Learning at once also pays off across the whole stack, because the same rules greet you in Power Apps, Power Automate, power BI, and the dynamics apps you may meet later. What to take away. If you remember one thing, make it the pairing. A security role is what someone can do and the access level plus the business unit decide how far that reaches. Once those two ideas click. A role name stops being a wall of checkboxes and starts reading like a sentence. I'll leave you with one question which part of Dataverse security still feels a little fuzzy? The roles themselves, or the way access levels and business units stack together. If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.