1 00:00:00,000 --> 00:00:02,520 So today's topic is one that almost everyone has heard of, 2 00:00:02,520 --> 00:00:05,400 but very few people actually understand security in data 3 00:00:05,400 --> 00:00:06,320 verse. 4 00:00:06,320 --> 00:00:09,520 Most people hear security and think passwords, licenses, 5 00:00:09,520 --> 00:00:12,040 or who can open an app and sure those things matter. 6 00:00:12,040 --> 00:00:14,680 But data verse security goes much deeper than that. 7 00:00:14,680 --> 00:00:16,440 Here's the simplest way to think about it. 8 00:00:16,440 --> 00:00:19,040 Data verse has three distinct layers of access control 9 00:00:19,040 --> 00:00:20,520 stacked on top of each other. 10 00:00:20,520 --> 00:00:23,240 The table level controls what actions someone can perform, 11 00:00:23,240 --> 00:00:25,640 the row level controls, which records they can actually 12 00:00:25,640 --> 00:00:28,360 see, and the column level protects individual fields 13 00:00:28,360 --> 00:00:29,240 within a record. 14 00:00:29,240 --> 00:00:30,800 By the end of this episode, you'll 15 00:00:30,800 --> 00:00:33,480 understand how these layers work together and why each one 16 00:00:33,480 --> 00:00:35,400 matters for keeping your data safe. 17 00:00:35,400 --> 00:00:38,080 Grab your coffee and let's break it down from the ground up. 18 00:00:38,080 --> 00:00:40,520 Security roles, who can do what on tables? 19 00:00:40,520 --> 00:00:43,360 Let's start with the most fundamental layer security roles. 20 00:00:43,360 --> 00:00:46,520 A security role defines the actions a user can perform 21 00:00:46,520 --> 00:00:50,760 on a specific table, create, read, write, delete, append, 22 00:00:50,760 --> 00:00:52,000 assign, share. 23 00:00:52,000 --> 00:00:53,920 Those are the basic building blocks of access. 24 00:00:53,920 --> 00:00:55,240 Think of it like a building pass. 25 00:00:55,240 --> 00:00:57,520 Some people get a pass that only lets them into the lobby. 26 00:00:57,520 --> 00:01:00,080 They can look around but can't enter any offices. 27 00:01:00,080 --> 00:01:01,320 And that's read only access. 28 00:01:01,320 --> 00:01:03,960 Other people get a pass that lets them into offices 29 00:01:03,960 --> 00:01:05,480 so they can write to records. 30 00:01:05,480 --> 00:01:07,200 And a few people get a pass that lets them 31 00:01:07,200 --> 00:01:09,280 remodel the whole floor, meaning they can 32 00:01:09,280 --> 00:01:11,120 delete and reassign permissions. 33 00:01:11,120 --> 00:01:14,520 Now security roles are assigned to users or teams inside 34 00:01:14,520 --> 00:01:16,000 a data verse environment. 35 00:01:16,000 --> 00:01:17,080 And here's the key point. 36 00:01:17,080 --> 00:01:19,280 Every single user needs at least one security role 37 00:01:19,280 --> 00:01:20,560 to do anything at all. 38 00:01:20,560 --> 00:01:22,200 No role means no access. 39 00:01:22,200 --> 00:01:24,040 The system simply won't let them in. 40 00:01:24,040 --> 00:01:26,760 Microsoft provides a set of pre-built roles to get you started. 41 00:01:26,760 --> 00:01:28,800 You've got basic user, the minimum for anyone 42 00:01:28,800 --> 00:01:31,960 who needs to interact with the system, system customizer, 43 00:01:31,960 --> 00:01:33,760 which lets people customize the environment, 44 00:01:33,760 --> 00:01:35,440 but not change security. 45 00:01:35,440 --> 00:01:38,600 System administrator, which is full access to everything, 46 00:01:38,600 --> 00:01:41,800 an environment maker, which lets people create resources 47 00:01:41,800 --> 00:01:44,480 but grants zero data access on its own. 48 00:01:44,480 --> 00:01:45,840 Each one comes with different defaults. 49 00:01:45,840 --> 00:01:47,960 Now this is where custom roles really shine. 50 00:01:47,960 --> 00:01:49,440 You don't have to build one from scratch, 51 00:01:49,440 --> 00:01:51,400 instead copy basic user as a starting point 52 00:01:51,400 --> 00:01:53,760 and tweak the permissions for your own custom tables. 53 00:01:53,760 --> 00:01:56,400 That way you keep all the default access users need 54 00:01:56,400 --> 00:01:59,520 while adding only the specific permissions your scenario requires. 55 00:01:59,520 --> 00:02:01,520 Once you know what actions a role allows, 56 00:02:01,520 --> 00:02:05,040 the next question is which specific rows can they see? 57 00:02:05,040 --> 00:02:07,520 That's where access levels come in. 58 00:02:07,520 --> 00:02:09,760 Access levels, the scope of that permission. 59 00:02:09,760 --> 00:02:12,280 A security role doesn't just say you can read. 60 00:02:12,280 --> 00:02:14,600 It says you can read this much of the data. 61 00:02:14,600 --> 00:02:16,640 That range is called the access level 62 00:02:16,640 --> 00:02:19,280 and it decides how far your view goes across the system. 63 00:02:19,280 --> 00:02:20,920 There are four main access levels. 64 00:02:20,920 --> 00:02:21,840 First is user. 65 00:02:21,840 --> 00:02:23,960 You only see records your own, then business unit 66 00:02:23,960 --> 00:02:26,240 where you see records from anyone in your department, 67 00:02:26,240 --> 00:02:27,680 parent child business units, 68 00:02:27,680 --> 00:02:30,440 extend that to include any sub-departments underneath yours. 69 00:02:30,440 --> 00:02:32,960 And finally, organization which gives you a full view 70 00:02:32,960 --> 00:02:35,040 of every record in the whole environment. 71 00:02:35,040 --> 00:02:36,640 Let me give you a concrete example. 72 00:02:36,640 --> 00:02:40,320 A sales rep might have read, user on the opportunities table. 73 00:02:40,320 --> 00:02:42,720 That means they only see their own deals, 74 00:02:42,720 --> 00:02:44,400 not their co-workers pipeline. 75 00:02:44,400 --> 00:02:48,680 A sales manager though might get read business unit. 76 00:02:48,680 --> 00:02:50,560 That lets them see the whole team's opportunities 77 00:02:50,560 --> 00:02:52,840 because they need that visibility to manage performance. 78 00:02:52,840 --> 00:02:55,320 Now here's something that trips up new admins all the time. 79 00:02:55,320 --> 00:02:56,600 Privileges are additive. 80 00:02:56,600 --> 00:02:58,840 If a user has two different security roles, 81 00:02:58,840 --> 00:03:00,520 the system doesn't average them out. 82 00:03:00,520 --> 00:03:03,120 It takes the least restrictive permission for each action. 83 00:03:03,120 --> 00:03:05,400 So if one role says read, user, 84 00:03:05,400 --> 00:03:08,120 and the other says read, organization, 85 00:03:08,120 --> 00:03:10,720 the user gets read, organization. 86 00:03:10,720 --> 00:03:12,360 The broader permission always wins. 87 00:03:12,360 --> 00:03:13,360 And here's the gotcha. 88 00:03:13,360 --> 00:03:14,760 Because permission stack up, 89 00:03:14,760 --> 00:03:17,400 you can't subtract access by adding another role. 90 00:03:17,400 --> 00:03:18,720 You only get more access. 91 00:03:18,720 --> 00:03:20,200 If you need to restrict someone, 92 00:03:20,200 --> 00:03:22,200 you have to remove the role giving them too much 93 00:03:22,200 --> 00:03:24,000 or use a different mechanism entirely. 94 00:03:24,000 --> 00:03:25,920 That mistake causes a lot of head scratching. 95 00:03:25,920 --> 00:03:27,600 So security roles control what you can do 96 00:03:27,600 --> 00:03:28,960 and how wide your view is. 97 00:03:28,960 --> 00:03:31,640 But the real data segmentation happens next 98 00:03:31,640 --> 00:03:33,280 with business units and teams. 99 00:03:33,280 --> 00:03:35,640 Business units, your organizational structure. 100 00:03:35,640 --> 00:03:37,520 We've covered what actions a user can take 101 00:03:37,520 --> 00:03:38,720 and how wide their view is. 102 00:03:38,720 --> 00:03:41,440 But in a real company, you don't want everyone seeing everything. 103 00:03:41,440 --> 00:03:43,000 That's where business units come in. 104 00:03:43,000 --> 00:03:45,160 Business units are basically your departments 105 00:03:45,160 --> 00:03:48,200 or divisions, sales, marketing, finance, support. 106 00:03:48,200 --> 00:03:51,040 They create a hierarchy that mirrors your actual org chart. 107 00:03:51,040 --> 00:03:53,280 And they're the main way to segment data in data verse. 108 00:03:53,280 --> 00:03:54,560 Here's how it works. 109 00:03:54,560 --> 00:03:57,480 Every user belongs to exactly one default business unit 110 00:03:57,480 --> 00:04:00,280 and records can own a business unit too. 111 00:04:00,280 --> 00:04:01,920 When a sales rep creates a new account, 112 00:04:01,920 --> 00:04:04,240 that record belongs to the sales business unit. 113 00:04:04,240 --> 00:04:06,240 This connection between user business unit 114 00:04:06,240 --> 00:04:09,480 and the records they create is the foundation of role level access. 115 00:04:09,480 --> 00:04:12,120 The classic model for business units was pretty strict. 116 00:04:12,120 --> 00:04:14,120 Users could only see records within their own unit 117 00:04:14,120 --> 00:04:15,720 in any child units beneath it. 118 00:04:15,720 --> 00:04:17,640 If you were in sales, you saw sales records, 119 00:04:17,640 --> 00:04:19,160 marketing, soul marketing records. 120 00:04:19,160 --> 00:04:20,760 Those two worlds never crossed. 121 00:04:20,760 --> 00:04:23,240 That worked fine for organizations with strict silos 122 00:04:23,240 --> 00:04:25,800 where departments operated completely independently. 123 00:04:25,800 --> 00:04:27,880 But the modernized model is much more flexible. 124 00:04:27,880 --> 00:04:29,120 Microsoft introduced something called 125 00:04:29,120 --> 00:04:31,120 a matrix data access structure. 126 00:04:31,120 --> 00:04:33,360 Instead of locking users into one business unit, 127 00:04:33,360 --> 00:04:35,880 you can assign security roles from multiple business units 128 00:04:35,880 --> 00:04:36,840 to a single user. 129 00:04:36,840 --> 00:04:39,200 So a user can access records across different units, 130 00:04:39,200 --> 00:04:41,680 even if they're not assigned to those units themselves. 131 00:04:41,680 --> 00:04:43,480 This is a big deal for cross-functional work. 132 00:04:43,480 --> 00:04:45,200 Imagine a marketing person in the US 133 00:04:45,200 --> 00:04:48,040 who needs to see campaign data from the European office. 134 00:04:48,040 --> 00:04:50,360 In the classic model, you'd have to jump through hoops 135 00:04:50,360 --> 00:04:51,240 to make that happen. 136 00:04:51,240 --> 00:04:54,360 In the modernized model, you just give them a security role 137 00:04:54,360 --> 00:04:56,960 from the European business unit with the right permissions. 138 00:04:56,960 --> 00:04:57,800 Simple. 139 00:04:57,800 --> 00:04:59,360 The owning business unit column on each record 140 00:04:59,360 --> 00:05:00,600 makes this possible. 141 00:05:00,600 --> 00:05:03,840 That column determines which business unit owns the record. 142 00:05:03,840 --> 00:05:05,840 Access is granted based on the security roles 143 00:05:05,840 --> 00:05:07,760 assigned from that business unit, regardless 144 00:05:07,760 --> 00:05:08,840 of where the user sits. 145 00:05:08,840 --> 00:05:11,320 The user's own business unit becomes less relevant. 146 00:05:11,320 --> 00:05:13,080 What matters is what roles they have and where 147 00:05:13,080 --> 00:05:14,320 those roles come from. 148 00:05:14,320 --> 00:05:16,680 You create business units through the power platform 149 00:05:16,680 --> 00:05:17,800 admin center. 150 00:05:17,800 --> 00:05:19,520 Set up a parent and child structure, 151 00:05:19,520 --> 00:05:21,800 head office at the top departments underneath, 152 00:05:21,800 --> 00:05:23,720 then assign users to the right unit. 153 00:05:23,720 --> 00:05:25,360 It takes a few minutes to configure, 154 00:05:25,360 --> 00:05:27,480 but it's one of those things you want to get right from the start 155 00:05:27,480 --> 00:05:29,920 because restructuring later is painful. 156 00:05:29,920 --> 00:05:31,600 But business units alone aren't enough. 157 00:05:31,600 --> 00:05:33,760 You also need teams to handle group ownership 158 00:05:33,760 --> 00:05:36,440 and shared access efficiently. 159 00:05:36,440 --> 00:05:37,160 Teams. 160 00:05:37,160 --> 00:05:38,680 Owning records as a group. 161 00:05:38,680 --> 00:05:41,040 Teams let groups of people own records together. 162 00:05:41,040 --> 00:05:44,560 Two main types matter here, owning teams and access teams. 163 00:05:44,560 --> 00:05:47,320 An owning team holds record ownership as a group. 164 00:05:47,320 --> 00:05:48,960 Imagine a sales team with five people. 165 00:05:48,960 --> 00:05:50,520 That team owns one account record. 166 00:05:50,520 --> 00:05:54,080 Any member can work on it, update it, assign tasks from it. 167 00:05:54,080 --> 00:05:55,640 The record doesn't belong to one person. 168 00:05:55,640 --> 00:05:56,760 It belongs to the whole group. 169 00:05:56,760 --> 00:05:59,040 That's perfect when multiple people need ongoing access 170 00:05:59,040 --> 00:06:00,400 to the same set of records. 171 00:06:00,400 --> 00:06:01,720 Access teams work differently. 172 00:06:01,720 --> 00:06:02,640 They don't own records. 173 00:06:02,640 --> 00:06:04,600 Instead, they're built for sharing specific records 174 00:06:04,600 --> 00:06:06,120 without changing ownership. 175 00:06:06,120 --> 00:06:08,200 Say, a support agent needs temporary access 176 00:06:08,200 --> 00:06:09,920 to a sales account to resolve a ticket. 177 00:06:09,920 --> 00:06:11,520 You add that account to an access team 178 00:06:11,520 --> 00:06:14,240 and the agent gets access without the record changing hands. 179 00:06:14,240 --> 00:06:15,760 Great for ad hoc collaboration. 180 00:06:15,760 --> 00:06:16,960 Now here's where it gets powerful. 181 00:06:16,960 --> 00:06:17,760 Group teams. 182 00:06:17,760 --> 00:06:20,520 You can link a team directly to a Microsoft EntraID Security 183 00:06:20,520 --> 00:06:21,000 group. 184 00:06:21,000 --> 00:06:23,200 When you do that, memberships things automatically. 185 00:06:23,200 --> 00:06:24,920 Add someone to the security group in Entra 186 00:06:24,920 --> 00:06:26,720 and they appear in the Dataverse team. 187 00:06:26,720 --> 00:06:28,800 Remove them from the group and they're gone from the team. 188 00:06:28,800 --> 00:06:30,200 No manual updates needed. 189 00:06:30,200 --> 00:06:33,360 That means you don't have to add users one by one in Dataverse. 190 00:06:33,360 --> 00:06:35,080 Just manage your groups in EntraID 191 00:06:35,080 --> 00:06:36,640 and the team updates itself. 192 00:06:36,640 --> 00:06:39,000 For large organizations, this saves a ton of time. 193 00:06:39,000 --> 00:06:41,080 You can manage thousands of users 194 00:06:41,080 --> 00:06:42,760 through a handful of security groups 195 00:06:42,760 --> 00:06:45,120 instead of clicking through admin screens all day. 196 00:06:45,120 --> 00:06:46,040 And here's the clean part. 197 00:06:46,040 --> 00:06:48,200 When you assign a security role to a team, 198 00:06:48,200 --> 00:06:50,320 every single member inherits those permissions. 199 00:06:50,320 --> 00:06:52,720 You don't assign the role to each person individually. 200 00:06:52,720 --> 00:06:55,760 You assign it once to the team and it applies to everyone. 201 00:06:55,760 --> 00:06:57,640 That's scalable, consistent and easy to audit. 202 00:06:57,640 --> 00:07:00,720 So now we've got roles controlling what actions users can take, 203 00:07:00,720 --> 00:07:03,080 business units, scoping which rows they can see 204 00:07:03,080 --> 00:07:05,000 and teams handling group access. 205 00:07:05,000 --> 00:07:07,320 But what about the most granular layer of all? 206 00:07:07,320 --> 00:07:09,120 Individual columns within a record. 207 00:07:09,120 --> 00:07:11,600 That's where field level security comes in. 208 00:07:11,600 --> 00:07:14,440 Field level security, hiding specific columns. 209 00:07:14,440 --> 00:07:17,080 So roles control what actions users can take. 210 00:07:17,080 --> 00:07:19,840 Business units and teams scope which rows they can see. 211 00:07:19,840 --> 00:07:21,760 But what if the problem isn't a whole record? 212 00:07:21,760 --> 00:07:23,120 What if you need to restrict access 213 00:07:23,120 --> 00:07:25,680 to just one single column inside a record? 214 00:07:25,680 --> 00:07:28,040 Think about a salary field on an employee record 215 00:07:28,040 --> 00:07:30,000 or a social security number on a contact 216 00:07:30,000 --> 00:07:31,760 or a credit card number on an account. 217 00:07:31,760 --> 00:07:33,680 You don't want to hide the entire record. 218 00:07:33,680 --> 00:07:35,680 The sales rep still needs to see the customers name 219 00:07:35,680 --> 00:07:36,600 and phone number. 220 00:07:36,600 --> 00:07:39,000 But that one field that needs to be locked down tight, 221 00:07:39,000 --> 00:07:42,400 field level security or FLS handles exactly the scenario. 222 00:07:42,400 --> 00:07:43,440 Here's how it works. 223 00:07:43,440 --> 00:07:45,680 You mark a specific column as secured. 224 00:07:45,680 --> 00:07:48,400 Then you create something called a field security profile. 225 00:07:48,400 --> 00:07:50,400 That profile defines which users or teams 226 00:07:50,400 --> 00:07:51,960 get access to that secured field. 227 00:07:51,960 --> 00:07:53,240 Only those people can see it. 228 00:07:53,240 --> 00:07:54,560 Here's how strict this really is. 229 00:07:54,560 --> 00:07:57,280 Without a field security profile, nobody can see that column. 230 00:07:57,280 --> 00:07:59,320 Not even a system administrator who owns the record. 231 00:07:59,320 --> 00:08:00,440 It's completely hidden. 232 00:08:00,440 --> 00:08:02,560 Or depending on how you configure it, masked. 233 00:08:02,560 --> 00:08:04,280 The field simply doesn't show up for anyone 234 00:08:04,280 --> 00:08:07,200 who isn't explicitly granted access through a profile. 235 00:08:07,200 --> 00:08:08,640 And this part surprises people. 236 00:08:08,640 --> 00:08:10,480 FLS overrides table level permissions. 237 00:08:10,480 --> 00:08:11,640 Let me say that again. 238 00:08:11,640 --> 00:08:13,480 The user might have read organization access 239 00:08:13,480 --> 00:08:14,800 on the contacts table. 240 00:08:14,800 --> 00:08:16,320 They can see every single contact record 241 00:08:16,320 --> 00:08:17,400 in the entire environment. 242 00:08:17,400 --> 00:08:20,120 But if the tax ID column on that table is secured 243 00:08:20,120 --> 00:08:21,720 and they don't have a profile for it, 244 00:08:21,720 --> 00:08:22,960 that column is blank. 245 00:08:22,960 --> 00:08:24,960 Table level permission doesn't help them. 246 00:08:24,960 --> 00:08:27,040 FLS sits on top and says no. 247 00:08:27,040 --> 00:08:29,680 Profiles themselves have three permissions you can grant. 248 00:08:29,680 --> 00:08:31,640 Read, update, and create. 249 00:08:31,640 --> 00:08:34,160 So you can let someone read a field but not change it. 250 00:08:34,160 --> 00:08:36,400 Or allow them to create records with that field, 251 00:08:36,400 --> 00:08:38,960 populate it but not edit existing values. 252 00:08:38,960 --> 00:08:40,960 Or give full access to a specific team 253 00:08:40,960 --> 00:08:42,400 while keeping everyone else out. 254 00:08:42,400 --> 00:08:44,080 That's granular control at the column level. 255 00:08:44,080 --> 00:08:46,080 FLS is powerful but you don't want to throw it 256 00:08:46,080 --> 00:08:47,560 at every column in your database. 257 00:08:47,560 --> 00:08:49,600 And there are limits and performance considerations 258 00:08:49,600 --> 00:08:50,920 you need to know about. 259 00:08:50,920 --> 00:08:53,840 FLS limits, masking, and best practices. 260 00:08:53,840 --> 00:08:55,800 So how many fields can you actually lock down 261 00:08:55,800 --> 00:08:57,240 with field level security? 262 00:08:57,240 --> 00:08:58,880 The answer is a few dozen, not hundreds. 263 00:08:58,880 --> 00:09:01,240 You can't secure every single column in a table. 264 00:09:01,240 --> 00:09:02,560 And honestly, you wouldn't want to. 265 00:09:02,560 --> 00:09:03,360 Here's why. 266 00:09:03,360 --> 00:09:06,040 Every secured field adds overhead to every query. 267 00:09:06,040 --> 00:09:08,640 The system checks user memberships, evaluates permissions 268 00:09:08,640 --> 00:09:10,400 and strips out hidden fields. 269 00:09:10,400 --> 00:09:13,200 Do that for one or two fields and the performance hit is tiny. 270 00:09:13,200 --> 00:09:15,040 Do it for 30 fields on a busy table 271 00:09:15,040 --> 00:09:16,920 and your apps start to feel sluggish. 272 00:09:16,920 --> 00:09:19,320 Use FLS sparingly. 273 00:09:19,320 --> 00:09:22,200 Now there's a feature that arrived around 2025 274 00:09:22,200 --> 00:09:23,320 that I really like. 275 00:09:23,320 --> 00:09:24,280 Column masking. 276 00:09:24,280 --> 00:09:25,880 Instead of hiding a field completely, 277 00:09:25,880 --> 00:09:27,800 you show part of it using regular expressions. 278 00:09:27,800 --> 00:09:30,040 For example, a customer support agent 279 00:09:30,040 --> 00:09:31,560 might see only the last four digits 280 00:09:31,560 --> 00:09:32,720 of a credit card number. 281 00:09:32,720 --> 00:09:33,720 The rest is masked. 282 00:09:33,720 --> 00:09:36,520 They can verify the card without ever seeing the full number. 283 00:09:36,520 --> 00:09:38,080 The masking is applied server side 284 00:09:38,080 --> 00:09:41,640 so it works consistently across forms, reports and API responses. 285 00:09:41,640 --> 00:09:44,400 There's also app access control, which lets you restrict 286 00:09:44,400 --> 00:09:47,000 which applications can interact with secured fields. 287 00:09:47,000 --> 00:09:50,240 You can block Excel desktop from reading sensitive data, for example. 288 00:09:50,240 --> 00:09:51,880 It's another layer of defense against someone 289 00:09:51,880 --> 00:09:53,920 trying to export data through a back door. 290 00:09:53,920 --> 00:09:56,000 And here's something that matters for mobile users. 291 00:09:56,000 --> 00:09:57,960 Offline caches respect FLS. 292 00:09:57,960 --> 00:09:59,800 When a user downloads data to their laptop 293 00:09:59,800 --> 00:10:01,200 or phone for offline use, 294 00:10:01,200 --> 00:10:03,040 secured fields don't come along. 295 00:10:03,040 --> 00:10:04,880 Sensitive data stays on the server. 296 00:10:04,880 --> 00:10:07,200 That's important for compliance with regulations 297 00:10:07,200 --> 00:10:08,720 like GDPR and HIPAA. 298 00:10:08,720 --> 00:10:10,080 So what's the best practice? 299 00:10:10,080 --> 00:10:11,520 Start with table level roles. 300 00:10:11,520 --> 00:10:13,040 That's your first line of defense, 301 00:10:13,040 --> 00:10:15,200 then add business units for row segmentation. 302 00:10:15,200 --> 00:10:16,240 That's your second layer. 303 00:10:16,240 --> 00:10:19,320 Only then use FLS for truly sensitive columns. 304 00:10:19,320 --> 00:10:22,360 Salary, tax ID, credit card numbers. 305 00:10:22,360 --> 00:10:24,640 Don't stack layers unless you actually need them. 306 00:10:24,640 --> 00:10:26,840 Every layer adds complexity and complexity 307 00:10:26,840 --> 00:10:28,680 is the enemy of a clean security model. 308 00:10:28,680 --> 00:10:30,440 So now you have the full picture. 309 00:10:30,440 --> 00:10:31,800 Three layers working together. 310 00:10:31,800 --> 00:10:33,080 But how do you actually troubleshoot 311 00:10:33,080 --> 00:10:35,280 when someone can't see what they should? 312 00:10:35,280 --> 00:10:37,000 Common pitfalls and troubleshooting. 313 00:10:37,000 --> 00:10:39,040 So let's talk about the things that actually go wrong. 314 00:10:39,040 --> 00:10:40,800 Because knowing the theory is one thing, 315 00:10:40,800 --> 00:10:44,080 but knowing where people trip up saves you hours of frustration. 316 00:10:44,080 --> 00:10:45,520 The most common mistake I see is this. 317 00:10:45,520 --> 00:10:47,240 Someone creates a custom security role, 318 00:10:47,240 --> 00:10:48,480 assigns it to a user, 319 00:10:48,480 --> 00:10:51,760 and then wonders why that user can't log into data verse at all. 320 00:10:51,760 --> 00:10:53,600 The answer is almost always the same. 321 00:10:53,600 --> 00:10:56,560 They forgot to also assign the basic user role. 322 00:10:56,560 --> 00:10:58,480 Basic user is the minimum set of permissions 323 00:10:58,480 --> 00:11:00,720 that let someone interact with the environment. 324 00:11:00,720 --> 00:11:02,920 Without it, your fancy custom role doesn't matter. 325 00:11:02,920 --> 00:11:05,480 The user can't even get through the door. 326 00:11:05,480 --> 00:11:06,640 Another one that catches people. 327 00:11:06,640 --> 00:11:08,040 You give a user too much access. 328 00:11:08,040 --> 00:11:10,800 So you assign them another role that you think will restrict them, 329 00:11:10,800 --> 00:11:11,760 but it doesn't work. 330 00:11:11,760 --> 00:11:13,920 Because permissions are additive, not subtractive. 331 00:11:13,920 --> 00:11:17,040 You can't use one role to take away what another role grants. 332 00:11:17,040 --> 00:11:18,720 The system always picks the broadest permission. 333 00:11:18,720 --> 00:11:20,280 If you need to restrict someone, 334 00:11:20,280 --> 00:11:22,880 you have to remove the over permissive role entirely, 335 00:11:22,880 --> 00:11:26,080 or use field-level security to lock down specific columns. 336 00:11:26,080 --> 00:11:27,240 There's no middle ground. 337 00:11:27,240 --> 00:11:29,400 Business unit misalignment is another classic. 338 00:11:29,400 --> 00:11:31,520 A user belongs to the sales business unit, 339 00:11:31,520 --> 00:11:32,960 but the record they need to see 340 00:11:32,960 --> 00:11:35,000 has an owning business unit of marketing. 341 00:11:35,000 --> 00:11:36,760 Even if they have read organization on that table, 342 00:11:36,760 --> 00:11:38,760 they might not see it in their default views. 343 00:11:38,760 --> 00:11:40,840 The record exists and the permission is technically there, 344 00:11:40,840 --> 00:11:42,400 but the view is filtered by business unit 345 00:11:42,400 --> 00:11:43,840 and nobody thinks to check that. 346 00:11:43,840 --> 00:11:45,640 Team ownership confuses people too. 347 00:11:45,640 --> 00:11:48,720 If a team owns a record, individual ownership doesn't apply. 348 00:11:48,720 --> 00:11:50,480 Only team members can modify it, 349 00:11:50,480 --> 00:11:53,400 unless a user has a higher access level like organization. 350 00:11:53,400 --> 00:11:56,600 So if someone says, "I can see the record, but I can't edit it," 351 00:11:56,600 --> 00:11:57,920 check who owns it first. 352 00:11:57,920 --> 00:11:59,880 If it's a team, they need to be on that team. 353 00:11:59,880 --> 00:12:02,160 And here's the one that took me an hour to find once. 354 00:12:02,160 --> 00:12:04,440 A user complains they can't see a field. 355 00:12:04,440 --> 00:12:07,520 You check their security role, full read on the table. 356 00:12:07,520 --> 00:12:09,920 You check the access level, organization. 357 00:12:09,920 --> 00:12:12,240 Everything looks fine, but the field is blank. 358 00:12:12,240 --> 00:12:13,640 You dig deeper and there it is. 359 00:12:13,640 --> 00:12:15,600 The field is secured with FLS. 360 00:12:15,600 --> 00:12:17,200 The user has table level access, 361 00:12:17,200 --> 00:12:18,640 but no field security profile, 362 00:12:18,640 --> 00:12:20,480 so the field is simply invisible to them. 363 00:12:20,480 --> 00:12:22,880 That one is easy to miss because the table level permission 364 00:12:22,880 --> 00:12:23,920 looks correct. 365 00:12:23,920 --> 00:12:26,720 These gotchas are easy to avoid once you know the patterns. 366 00:12:26,720 --> 00:12:30,320 Let's wrap up with how all three layers fit together in practice. 367 00:12:30,320 --> 00:12:31,880 The three layers working together. 368 00:12:31,880 --> 00:12:33,360 So here's how it all fits together. 369 00:12:33,360 --> 00:12:36,040 Security roles control what you can do on a table. 370 00:12:36,040 --> 00:12:38,240 Create, read, update, delete. 371 00:12:38,240 --> 00:12:40,960 Business units and teams decide which rows you can see. 372 00:12:40,960 --> 00:12:43,200 And field level security protects individual columns 373 00:12:43,200 --> 00:12:44,360 from prying eyes. 374 00:12:44,360 --> 00:12:46,280 Three layers and you really need all of them 375 00:12:46,280 --> 00:12:47,880 for a complete security model. 376 00:12:47,880 --> 00:12:50,600 Think of it like a physical building with three checkpoints. 377 00:12:50,600 --> 00:12:52,040 First, your badge lets you in the door. 378 00:12:52,040 --> 00:12:53,240 That's your security role. 379 00:12:53,240 --> 00:12:55,200 Second, you can only walk into your own department. 380 00:12:55,200 --> 00:12:56,280 That's your business unit. 381 00:12:56,280 --> 00:12:58,200 Third, certain filing cabinets are locked 382 00:12:58,200 --> 00:12:59,880 and only certain people can open them. 383 00:12:59,880 --> 00:13:01,120 That's field level security. 384 00:13:01,120 --> 00:13:03,080 Each layer builds on the one before it. 385 00:13:03,080 --> 00:13:04,440 Your next step is simple. 386 00:13:04,440 --> 00:13:05,640 Open your own environment. 387 00:13:05,640 --> 00:13:08,280 Find a table that might need row or column restrictions. 388 00:13:08,280 --> 00:13:10,840 Start small, duplicate the basic user role, 389 00:13:10,840 --> 00:13:13,320 create a test team, add one secured field, 390 00:13:13,320 --> 00:13:14,600 watch how the layers interact, 391 00:13:14,600 --> 00:13:17,040 nothing teaches faster than doing it yourself. 392 00:13:17,040 --> 00:13:18,960 Subscribe on your favorite podcast platform 393 00:13:18,960 --> 00:13:20,280 and share this episode with someone 394 00:13:20,280 --> 00:13:21,960 starting their database journey.