Dataverse Security - Simply Explained

So today's topic is one that almost everyone has heard of, but very few people actually understand security in data verse. Most people hear security and think passwords, licenses, or who can open an app and sure those things matter. But data verse security goes much deeper than that. Here's the simplest way to think about it. Data verse has three distinct layers of access control stacked on top of each other. The table level controls what actions someone can perform, the row level controls, which records they can actually see, and the column level protects individual fields within a record. By the end of this episode, you'll understand how these layers work together and why each one matters for keeping your data safe. Grab your coffee and let's break it down from the ground up. Security roles, who can do what on tables? Let's start with the most fundamental layer security roles. A security role defines the actions a user can perform on a specific table, create, read, write, delete, append, assign, share. Those are the basic building blocks of access. Think of it like a building pass. Some people get a pass that only lets them into the lobby. They can look around but can't enter any offices. And that's read only access. Other people get a pass that lets them into offices so they can write to records. And a few people get a pass that lets them remodel the whole floor, meaning they can delete and reassign permissions. Now security roles are assigned to users or teams inside a data verse environment. And here's the key point. Every single user needs at least one security role to do anything at all. No role means no access. The system simply won't let them in. Microsoft provides a set of pre-built roles to get you started. You've got basic user, the minimum for anyone who needs to interact with the system, system customizer, which lets people customize the environment, but not change security. System administrator, which is full access to everything, an environment maker, which lets people create resources but grants zero data access on its own. Each one comes with different defaults. Now this is where custom roles really shine. You don't have to build one from scratch, instead copy basic user as a starting point and tweak the permissions for your own custom tables. That way you keep all the default access users need while adding only the specific permissions your scenario requires. Once you know what actions a role allows, the next question is which specific rows can they see? That's where access levels come in. Access levels, the scope of that permission. A security role doesn't just say you can read. It says you can read this much of the data. That range is called the access level and it decides how far your view goes across the system. There are four main access levels. First is user. You only see records your own, then business unit where you see records from anyone in your department, parent child business units, extend that to include any sub-departments underneath yours. And finally, organization which gives you a full view of every record in the whole environment. Let me give you a concrete example. A sales rep might have read, user on the opportunities table. That means they only see their own deals, not their co-workers pipeline. A sales manager though might get read business unit. That lets them see the whole team's opportunities because they need that visibility to manage performance. Now here's something that trips up new admins all the time. Privileges are additive. If a user has two different security roles, the system doesn't average them out. It takes the least restrictive permission for each action. So if one role says read, user, and the other says read, organization, the user gets read, organization. The broader permission always wins. And here's the gotcha. Because permission stack up, you can't subtract access by adding another role. You only get more access. If you need to restrict someone, you have to remove the role giving them too much or use a different mechanism entirely. That mistake causes a lot of head scratching. So security roles control what you can do and how wide your view is. But the real data segmentation happens next with business units and teams. Business units, your organizational structure. We've covered what actions a user can take and how wide their view is. But in a real company, you don't want everyone seeing everything. That's where business units come in. Business units are basically your departments or divisions, sales, marketing, finance, support. They create a hierarchy that mirrors your actual org chart. And they're the main way to segment data in data verse. Here's how it works. Every user belongs to exactly one default business unit and records can own a business unit too. When a sales rep creates a new account, that record belongs to the sales business unit. This connection between user business unit and the records they create is the foundation of role level access. The classic model for business units was pretty strict. Users could only see records within their own unit in any child units beneath it. If you were in sales, you saw sales records, marketing, soul marketing records. Those two worlds never crossed. That worked fine for organizations with strict silos where departments operated completely independently. But the modernized model is much more flexible. Microsoft introduced something called a matrix data access structure. Instead of locking users into one business unit, you can assign security roles from multiple business units to a single user. So a user can access records across different units, even if they're not assigned to those units themselves. This is a big deal for cross-functional work. Imagine a marketing person in the US who needs to see campaign data from the European office. In the classic model, you'd have to jump through hoops to make that happen. In the modernized model, you just give them a security role from the European business unit with the right permissions. Simple. The owning business unit column on each record makes this possible. That column determines which business unit owns the record. Access is granted based on the security roles assigned from that business unit, regardless of where the user sits. The user's own business unit becomes less relevant. What matters is what roles they have and where those roles come from. You create business units through the power platform admin center. Set up a parent and child structure, head office at the top departments underneath, then assign users to the right unit. It takes a few minutes to configure, but it's one of those things you want to get right from the start because restructuring later is painful. But business units alone aren't enough. You also need teams to handle group ownership and shared access efficiently. Teams. Owning records as a group. Teams let groups of people own records together. Two main types matter here, owning teams and access teams. An owning team holds record ownership as a group. Imagine a sales team with five people. That team owns one account record. Any member can work on it, update it, assign tasks from it. The record doesn't belong to one person. It belongs to the whole group. That's perfect when multiple people need ongoing access to the same set of records. Access teams work differently. They don't own records. Instead, they're built for sharing specific records without changing ownership. Say, a support agent needs temporary access to a sales account to resolve a ticket. You add that account to an access team and the agent gets access without the record changing hands. Great for ad hoc collaboration. Now here's where it gets powerful. Group teams. You can link a team directly to a Microsoft EntraID Security group. When you do that, memberships things automatically. Add someone to the security group in Entra and they appear in the Dataverse team. Remove them from the group and they're gone from the team. No manual updates needed. That means you don't have to add users one by one in Dataverse. Just manage your groups in EntraID and the team updates itself. For large organizations, this saves a ton of time. You can manage thousands of users through a handful of security groups instead of clicking through admin screens all day. And here's the clean part. When you assign a security role to a team, every single member inherits those permissions. You don't assign the role to each person individually. You assign it once to the team and it applies to everyone. That's scalable, consistent and easy to audit. So now we've got roles controlling what actions users can take, business units, scoping which rows they can see and teams handling group access. But what about the most granular layer of all? Individual columns within a record. That's where field level security comes in. Field level security, hiding specific columns. So roles control what actions users can take. Business units and teams scope which rows they can see. But what if the problem isn't a whole record? What if you need to restrict access to just one single column inside a record? Think about a salary field on an employee record or a social security number on a contact or a credit card number on an account. You don't want to hide the entire record. The sales rep still needs to see the customers name and phone number. But that one field that needs to be locked down tight, field level security or FLS handles exactly the scenario. Here's how it works. You mark a specific column as secured. Then you create something called a field security profile. That profile defines which users or teams get access to that secured field. Only those people can see it. Here's how strict this really is. Without a field security profile, nobody can see that column. Not even a system administrator who owns the record. It's completely hidden. Or depending on how you configure it, masked. The field simply doesn't show up for anyone who isn't explicitly granted access through a profile. And this part surprises people. FLS overrides table level permissions. Let me say that again. The user might have read organization access on the contacts table. They can see every single contact record in the entire environment. But if the tax ID column on that table is secured and they don't have a profile for it, that column is blank. Table level permission doesn't help them. FLS sits on top and says no. Profiles themselves have three permissions you can grant. Read, update, and create. So you can let someone read a field but not change it. Or allow them to create records with that field, populate it but not edit existing values. Or give full access to a specific team while keeping everyone else out. That's granular control at the column level. FLS is powerful but you don't want to throw it at every column in your database. And there are limits and performance considerations you need to know about. FLS limits, masking, and best practices. So how many fields can you actually lock down with field level security? The answer is a few dozen, not hundreds. You can't secure every single column in a table. And honestly, you wouldn't want to. Here's why. Every secured field adds overhead to every query. The system checks user memberships, evaluates permissions and strips out hidden fields. Do that for one or two fields and the performance hit is tiny. Do it for 30 fields on a busy table and your apps start to feel sluggish. Use FLS sparingly. Now there's a feature that arrived around 2025 that I really like. Column masking. Instead of hiding a field completely, you show part of it using regular expressions. For example, a customer support agent might see only the last four digits of a credit card number. The rest is masked. They can verify the card without ever seeing the full number. The masking is applied server side so it works consistently across forms, reports and API responses. There's also app access control, which lets you restrict which applications can interact with secured fields. You can block Excel desktop from reading sensitive data, for example. It's another layer of defense against someone trying to export data through a back door. And here's something that matters for mobile users. Offline caches respect FLS. When a user downloads data to their laptop or phone for offline use, secured fields don't come along. Sensitive data stays on the server. That's important for compliance with regulations like GDPR and HIPAA. So what's the best practice? Start with table level roles. That's your first line of defense, then add business units for row segmentation. That's your second layer. Only then use FLS for truly sensitive columns. Salary, tax ID, credit card numbers. Don't stack layers unless you actually need them. Every layer adds complexity and complexity is the enemy of a clean security model. So now you have the full picture. Three layers working together. But how do you actually troubleshoot when someone can't see what they should? Common pitfalls and troubleshooting. So let's talk about the things that actually go wrong. Because knowing the theory is one thing, but knowing where people trip up saves you hours of frustration. The most common mistake I see is this. Someone creates a custom security role, assigns it to a user, and then wonders why that user can't log into data verse at all. The answer is almost always the same. They forgot to also assign the basic user role. Basic user is the minimum set of permissions that let someone interact with the environment. Without it, your fancy custom role doesn't matter. The user can't even get through the door. Another one that catches people. You give a user too much access. So you assign them another role that you think will restrict them, but it doesn't work. Because permissions are additive, not subtractive. You can't use one role to take away what another role grants. The system always picks the broadest permission. If you need to restrict someone, you have to remove the over permissive role entirely, or use field-level security to lock down specific columns. There's no middle ground. Business unit misalignment is another classic. A user belongs to the sales business unit, but the record they need to see has an owning business unit of marketing. Even if they have read organization on that table, they might not see it in their default views. The record exists and the permission is technically there, but the view is filtered by business unit and nobody thinks to check that. Team ownership confuses people too. If a team owns a record, individual ownership doesn't apply. Only team members can modify it, unless a user has a higher access level like organization. So if someone says, "I can see the record, but I can't edit it," check who owns it first. If it's a team, they need to be on that team. And here's the one that took me an hour to find once. A user complains they can't see a field. You check their security role, full read on the table. You check the access level, organization. Everything looks fine, but the field is blank. You dig deeper and there it is. The field is secured with FLS. The user has table level access, but no field security profile, so the field is simply invisible to them. That one is easy to miss because the table level permission looks correct. These gotchas are easy to avoid once you know the patterns. Let's wrap up with how all three layers fit together in practice. The three layers working together. So here's how it all fits together. Security roles control what you can do on a table. Create, read, update, delete. Business units and teams decide which rows you can see. And field level security protects individual columns from prying eyes. Three layers and you really need all of them for a complete security model. Think of it like a physical building with three checkpoints. First, your badge lets you in the door. That's your security role. Second, you can only walk into your own department. That's your business unit. Third, certain filing cabinets are locked and only certain people can open them. That's field level security. Each layer builds on the one before it. Your next step is simple. Open your own environment. Find a table that might need row or column restrictions. Start small, duplicate the basic user role, create a test team, add one secured field, watch how the layers interact, nothing teaches faster than doing it yourself. Subscribe on your favorite podcast platform and share this episode with someone starting their database journey.