Configuring Dataverse Column Security Profiles and Field-Level Permission Assignments: Restricting Sensitive Column Access Across Security Roles, Teams, and Users in Model-Driven Apps

Introduction

Imagine you've built a polished model-driven app for your HR department. Managers can view employee records, update job titles, and track performance — everything working exactly as designed. Then you realize that every manager, every recruiter, and every department head can also see the Salary column you added six months ago. It's right there on the form, visible to anyone with the Employee table's read privilege. No one meant for that to happen; table-level security just wasn't granular enough to stop it.

This is the gap that Dataverse Column Security Profiles were built to fill. Table-level security controls whether a user can read, create, update, or delete an entire record. Column security controls whether a user can read, create, or update a specific field within that record — even if they can see the record itself. It's the difference between "you can access this filing cabinet" and "you can open this filing cabinet, but not the drawer marked Compensation & Benefits." Once you understand this distinction, you'll start seeing column security as a non-negotiable layer in any app that handles PII, financial data, health information, or any other sensitive attributes.

By the end of this lesson, you'll have a thorough, working knowledge of how Dataverse column security profiles are structured, how to create and configure them, and how to assign them to security roles, teams, and individual users with full awareness of the edge cases that trip up even experienced makers.

What you'll learn:

• How column-level security works architecturally in Dataverse and how it interacts with table-level security roles
• How to enable column security on individual columns and what happens under the hood when you do
• How to create Column Security Profiles and configure read, create, and update permissions on protected columns
• How to assign profiles to security roles, teams, and individual users — and which assignment method wins when they conflict
• How column security interacts with views, forms, Power Automate flows, the API, and auditing
• How to avoid the common failure modes that expose data or lock users out unexpectedly

---

Prerequisites

Before diving in, you should have a solid working knowledge of:

• Dataverse tables, columns, and records — if you need a refresher, Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers covers the core concepts well
• How table-level security works with security roles, business units, and teams — Dataverse Security: Business Units, Security Roles, and Teams is the required reading here
• Basic familiarity with model-driven app forms — Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms will give you the context to understand how column security surfaces in the UI

You should also have the System Administrator or System Customizer role in the environment where you're working, since column security configuration requires those elevated privileges.

---

Understanding Column Security Architecture

Before touching any configuration, you need to understand the data model behind column security — because the moment you treat it as a simple checkbox, you'll create a false sense of security or accidentally lock yourself out of your own data.

The Two-Layer Security Model

Dataverse security operates in two distinct layers, and both must grant access for a user to read or write a value.

Layer 1 — Table-level security: A user's security role grants (or denies) privileges on a table as a whole. If a role grants Read access to the Employee table at the Organization level, any user with that role can retrieve Employee records. This is where most makers spend their security configuration time.

Layer 2 — Column-level security (CLS): When column security is enabled on a specific column, Dataverse adds an additional check beyond the table-level privilege. Even if a user's role grants Read on the Employee table, they can only see the value in the cr7a3_salary column if they are also assigned a Column Security Profile that grants read permission on that column.

These two layers are independent. You cannot grant column-level access if the user lacks table-level access — column security never elevates a user's table privileges. But you can absolutely restrict column access even when a user has full table access. The combination is what enables the fine-grained model.

The Role of the FieldSecurityProfile Entity

Under the hood, a Column Security Profile is a FieldSecurityProfile record. Each profile contains a set of FieldPermission child records — one per secured column — that specify the allowed operations (Read, Create, Update) as true/false values. When a user attempts to read or write a secured column, Dataverse evaluates whether any of the FieldSecurityProfiles associated with that user (directly or through team membership) grants the required permission.

This is an any-grants model, not a least-privilege model. If a user has three profiles assigned and one of them grants Read on cr7a3_salary, the user can read salary — even if the other two profiles deny it. There is no "deny" permission; absence of a permissive profile is the denial. This design matters enormously when you start stacking profiles across teams and roles.

What Happens to a Secured Column Without a Profile Assignment

When you enable column security on a column and a user reads a record without having any profile that grants read access on that column, one of two things happens depending on context:

• In a model-driven form: The field is rendered but its value is replaced with asterisks (****). The user knows the field exists but cannot see its content.
• Via the API (OData/WebAPI): The field is simply omitted from the response payload. No asterisks — just absence.
• In a view/grid: If the column is included in a view, users without read permission see the column header but no data.

This distinction matters especially if you're building integrations. A Power Automate flow running under a service account that lacks the correct profile will silently receive empty values rather than an error — a failure mode that can be very hard to diagnose.

---

Enabling Column Security on a Column

Column security is not on by default. You explicitly opt individual columns into the system. Let's walk through this for a realistic scenario: you're building an employee management app, and you need to restrict access to Annual Salary, Social Security Number, and Performance Rating.

Step 1: Navigate to the Column in Power Apps Studio

Open make.powerapps.com, select your environment, and navigate to Tables in the left navigation. Open the Employee table (or whatever your target table is). Select the Columns tab to see all columns on the table.

Find the column you want to secure — say, Annual Salary (logical name cr7a3_annualsalary). Click to open the column's property panel.

Step 2: Enable the Column Security Setting

In the column editor, scroll down until you find the Enable column security toggle (sometimes labeled Field Security depending on the maker portal version you're using). Flip it on and save the column.

This single toggle is what registers the column with the column security subsystem. Once enabled:

1. Dataverse creates a FieldPermission record with all three permissions set to false (no read, no create, no update) for every existing Column Security Profile in the environment.
2. Any existing security role configuration is unchanged — table-level access stays exactly as it was.
3. Immediately, any user without an assigned profile that grants read access will see asterisks instead of salary values.

Step 3: Repeat for Each Column You're Securing

Column security is enabled per-column. You'll repeat this process for Social Security Number and Performance Rating. You can also enable column security via the solution XML if you're automating deployments, which is the recommended approach for managed solution environments. The relevant XML attribute in the column definition is:

<attribute>
  <LogicalName>cr7a3_annualsalary</LogicalName>
  <IsSecured>1</IsSecured>
  ...
</attribute>

Setting IsSecured to 1 in your solution's customizations.xml achieves the same result as the UI toggle and travels cleanly through solution import.

---

Creating Column Security Profiles

A Column Security Profile is essentially a named permission set that you'll assign to users and teams. Think of it as analogous to a security role, but scoped entirely to column-level permissions rather than table-level privileges.

Good profile naming and scoping strategy is where experienced makers diverge from beginners. The temptation is to create one profile per table ("Employee Column Access") but this quickly becomes unmanageable. Better practice is to create profiles that map to job function access needs, which may cut across tables.

Designing Your Profile Structure

For our HR scenario, let's say we have three distinct access needs:

Profile Name	Who gets it	What they can do
HR Compensation Reviewer	HR Business Partners, Compensation Analysts	Read salary; cannot update
HR Compensation Manager	HR Directors, CHRO	Read + Update salary
HR Full Access	HR System Admins	Read + Create + Update all secured HR columns
Recruiter Limited Access	Recruiters	Read performance rating; no salary access

This design gives you four profiles to manage rather than trying to accommodate all variations in one. It also makes auditing clear: when you need to know who can read salary data, you look at who is assigned HR Compensation Reviewer or HR Compensation Manager or HR Full Access.

Creating a Profile in the Power Platform Admin Center

Column Security Profiles are managed in the Power Platform Admin Center (admin.powerplatform.microsoft.com), not in the Power Apps maker portal. This is a common source of confusion.

Navigate to your environment, then go to Settings > Users + permissions > Column security profiles. Select + New profile, enter a name and optional description, and save.

After saving, the profile editor opens. You'll see a tab called Field Permissions (sometimes it's accessed via the Related tab on older UIs). This is where you define what each secured column allows for this profile.

Configuring Field Permissions Within a Profile

In the Field Permissions tab, you'll see a list of every column in the environment that has column security enabled. For each column, you can set:

• Read: Can users with this profile read the column value?
• Create: Can users with this profile set the column value when creating a new record?
• Update: Can users with this profile change the column value on an existing record?

For the HR Compensation Reviewer profile:

• cr7a3_annualsalary → Read: Yes, Create: No, Update: No
• cr7a3_socialsecuritynumber → Read: No, Create: No, Update: No
• cr7a3_performancerating → Read: No, Create: No, Update: No

For the HR Compensation Manager profile:

• cr7a3_annualsalary → Read: Yes, Create: No, Update: Yes
• cr7a3_socialsecuritynumber → Read: Yes, Create: No, Update: No
• cr7a3_performancerating → Read: Yes, Create: No, Update: Yes

You set these by opening each field permission record and changing the picklist values from "No" to "Yes" for the desired operations.

Here's a minimal API call structure (using OData) to update a field permission record programmatically:

PATCH https://yourorg.crm.dynamics.com/api/data/v9.2/fieldpermissions(GUID)
Content-Type: application/json

{
  "canread": 4,
  "cancreate": 1,
  "canupdate": 1
}

The integer values map to the field_security_types option set: 1 = Not Allowed, 4 = Allowed. Yes, that's a quirky choice — 4 for allowed, not 1. The gap in the numbering is historical baggage, so don't let it trip you up when scripting.

---

Assigning Profiles to Security Roles, Teams, and Users

This is where the architecture gets genuinely interesting — and where most column security mistakes are made.

Assignment via Security Role Association

You can associate a Column Security Profile directly with a Security Role. When a user has a role that's associated with a profile, they inherit the profile's column permissions. This is the most scalable assignment method because it follows your existing role structure.

To add this association, open the Column Security Profile in the Power Platform Admin Center. Navigate to the Security roles tab (or Related > Security roles) and add the roles you want to associate. Every user with those roles in this environment will now have the profile's permissions applied.

In our example, the HR Compensation Reviewer profile would be associated with the HR Business Partner and Compensation Analyst security roles.

Assignment via Team Membership

Teams are often the more flexible assignment mechanism, especially for column security that needs to change dynamically (e.g., an employee joins or leaves the compensation committee). When a Column Security Profile is assigned to a team, every member of that team inherits the profile.

To assign a profile to a team, open the profile in Power Platform Admin Center, go to the Teams tab, and add your teams. You can assign to both Owner Teams and Access Teams (though owner teams are more commonly used for column security, as access teams are typically created dynamically per record for sharing scenarios).

Direct User Assignment

You can also assign a profile directly to a specific user. Navigate to the profile's Users tab and add users individually. This is appropriate for:

• A single executive who needs compensation access regardless of their team membership
• A temporary assignment while someone is covering a role
• A service account used by an integration flow

Direct user assignment is straightforward but creates governance overhead — it's harder to audit and maintain than role or team-based assignment. Use it sparingly.

How Assignments Combine: The Additive Model in Practice

Remember the additive, grant-only model mentioned earlier. When evaluating whether User A can read cr7a3_annualsalary, Dataverse checks:

1. All profiles directly assigned to User A
2. All profiles assigned to any team User A belongs to
3. All profiles associated with any security role User A holds

If any of these results in a profile where canread = 4 (Allowed) for cr7a3_annualsalary, the user can read the field. Period.

This means if you accidentally assign the HR Full Access profile to a broad team (say, the root business unit's default team), every user in the environment gets full column access — completely defeating the purpose. This is by far the most common serious mistake with column security.

---

Column Security Interaction with Forms and Views

Understanding how column security surfaces in the UI is critical for both designing good user experiences and diagnosing problems.

Forms and the Asterisk Rendering

When a user without read access opens a record containing a secured column, the form renders the field with **** (asterisks) as a placeholder. The form itself doesn't hide the field — it shows the field label, the control widget, and the masked value. This is intentional: hiding the field entirely could confuse users who expect to see it, and the masking makes it clear that data exists but is restricted.

If you want the field to be completely invisible to users without access, you have two options:

1. Add JavaScript to the form's OnLoad event to hide the control based on a check — but this is client-side only and doesn't constitute a security boundary
2. Create separate forms for different roles and use form-level security through role-based form assignment in combination with column security

The second approach is more robust. Users with restricted column access get a form variant that simply doesn't include those fields. Column security remains the enforcement layer; the form design provides the UX cleanliness.

Views and Column Security

If a secured column is included in a view, users without read access will see the column in the view grid but the cells will be empty — not asterisked, just blank. This can be confusing because it looks like the field simply has no data. When designing views that include secured columns, consider whether the column belongs in a view at all for general audiences.

From a view configuration perspective, you should create role-specific views that include secured columns only for views surfaced to users who will have the necessary profile assigned. While this doesn't prevent a user from adding the column to their personal view, it keeps the default experience coherent.

Quick View Forms and Column Security

Quick view forms — the summarized record views that appear when you hover over a lookup field — also respect column security. If a quick view form includes a secured column and the viewing user lacks read permission, they'll see asterisks in the quick view panel. This is important to know because quick view forms are often designed by people who don't think about column security; the rendering behavior can seem like a bug until you understand what's happening.

---

Column Security and the Dataverse API

The interaction between column security and API access is where things get operationally serious, especially in complex environments with multiple integrations.

OData / Web API Behavior

When a call to the Dataverse Web API retrieves a record containing a secured column, the response depends on the calling user's (or application user's) column security profile:

• If read is allowed, the column appears in the response with its value
• If read is not allowed, the column is silently omitted from the response

There is no HTTP 403 Forbidden response for individual fields. The record itself returns successfully; the field simply isn't there. This means any integration that processes these fields needs to handle null/missing gracefully and should be tested under the actual service principal identity.

For write operations:

• If a PATCH or POST payload includes a secured column and the calling user lacks create/update permission, the entire request fails with a 403 error — not just the field. This asymmetry between read (silent omission) and write (hard failure) is architecturally significant.

Fetch XML and Advanced Find

When you execute a FetchXML query that includes a secured column in its <attribute> list, the same rules apply: the column is omitted from results if the user lacks read access. If you use an <order> or <filter> on a secured column and lack read access, the behavior is environment-version-dependent but generally the filter is silently ignored or the query fails. Don't rely on filtering secured columns for security enforcement — a user without read access shouldn't be issuing those queries at all.

Service Accounts and Application Users

Power Automate flows, Azure Logic Apps, and other automated integrations run under either:

1. The flow creator's identity (common in personal flows)
2. A service principal / application user (best practice for enterprise flows)

Application users (non-interactive users authenticated via Azure AD app registration) are subject to column security just like regular users. To grant an application user access to secured columns, you must assign a Column Security Profile directly to that user record in Dataverse (since app users can't hold security roles the same way interactive users can in some configurations, though they can be assigned to teams).

The reliable pattern is to create a dedicated team (e.g., "Integration Service Accounts"), assign appropriate Column Security Profiles to that team, and add your application users to the team. This gives you clear governance and a single place to manage integration permissions.

---

Column Security in Business Rules, Plugins, and Calculated Columns

Column security interacts with platform features in non-obvious ways that you need to understand before deploying.

Business Rules

Business rules in Dataverse that reference secured columns are evaluated server-side, so the platform's system context (which has full access to all column values) executes the rule logic regardless of the current user's column security profile. This means a business rule can read a salary value and set a hidden field based on it — and the business rule will work correctly even if the triggering user can't see the salary column directly.

However, a business rule that displays a value by setting another field's value will surface that derived value to the user. Indirectly exposing secured data through business rule outputs is a real concern and requires careful design.

Formula Columns and Rollup Columns

Formula columns and rollup columns that reference secured columns are more nuanced. The calculation itself runs in system context and will access the secured column's value. But whether the result of the formula is visible depends on whether the formula column itself is secured.

If you create a formula column like AnnualSalary / 12 to show monthly salary, and that formula column is not secured, users who cannot see cr7a3_annualsalary might still be able to compute the salary from the formula column's visible result. This is a data leakage pattern that's easy to miss. The correct approach: if the source column is sensitive, the derived column should either also be secured or structured so the result doesn't reveal the source value.

Plugins and Server-Side Code

Plugins executing in system context (which is the default for synchronous plugins registered with a specific user account that has System Administrator) can read and write secured columns regardless of column security settings. This is by design — the server layer needs unrestricted data access to perform operations. If you have a plugin that writes audit information to a secured column, it will work fine. But be aware that plugins cannot be used to bypass column security for end-user operations — the enforcement happens at the data access layer before the plugin firing for retrieves.

---

Auditing Column Security Access

Given that column security protects your most sensitive data, knowing who accessed what and when is critical. For regulated industries, it's not optional.

Dataverse auditing, when enabled for a table and column, records read and write operations. Importantly, auditing operates independently of column security — even attempts to access secured columns that result in masked values can be logged if you configure audit to track reads.

For the most complete picture, enable auditing on both the table and the individual secured columns. You can view this audit history in the model-driven app's audit log views. For a deeper walkthrough of how to configure this, see Configuring Dataverse Auditing and Field-Level Change History in Model-Driven Apps.

---

Column Security in Solutions and ALM

If you're building in a proper application lifecycle management (ALM) pipeline — which you should be for any production system — you need to understand how column security travels through solutions.

What Travels in a Solution

When you export a solution, the following column security artifacts are included automatically:

• The IsSecured flag on column definitions (travels as part of the table component)
• Column Security Profile definitions (can be added as solution components)
• Field Permission records within those profiles

What does not automatically travel is:

• Profile assignments to users
• Profile assignments to teams
• Profile associations to security roles

This is a deliberate design decision: user and team membership is environment-specific. You cannot (and should not) have a managed solution that prescribes which users have access to sensitive columns in a production environment.

This creates an ALM challenge: your deployment process needs a post-import step that configures profile assignments in the target environment. Common approaches include:

1. A Power Automate cloud flow that's triggered after solution import and configures assignments
2. A configuration data package (using the Configuration Migration Tool) that includes FieldSecurityProfile-to-team/role associations
3. A Power Platform CLI script that applies assignments as part of your CI/CD pipeline

Managed Properties and Column Security Profiles

You can lock Column Security Profile definitions using managed properties if you're shipping a managed solution to a customer or downstream environment. This prevents administrators in the target environment from modifying the profile's field permissions. However, they can still assign or remove users, teams, and roles from the profile — managed properties cannot control those associations. For ISV-grade solutions, this is usually the right balance: you control the permission definitions, the customer controls the assignments.

---

Hands-On Exercise

This exercise walks you through a complete end-to-end column security configuration for a hypothetical financial services scenario. You'll secure a column, build profiles, assign them, and verify the behavior.

Scenario: You have a Loan Application table with a Credit Score column (cr8b1_creditscore) that should be visible only to Loan Officers and Credit Analysts, not to general Customer Service Representatives.

Step 1: Enable Column Security on Credit Score

1. In Power Apps maker portal, open your environment and navigate to Tables > Loan Application > Columns
2. Open the Credit Score column
3. Enable Column security and save the column
4. Verify: open a Loan Application record as a Customer Service Rep user — confirm you see **** where the credit score value should appear

Step 2: Create the "Loan Officer Credit Access" Profile

1. Navigate to Power Platform Admin Center > your environment > Settings > Users + permissions > Column security profiles
2. Select + New profile and name it Loan Officer Credit Access
3. Save the profile, then open the Field Permissions tab
4. Find cr8b1_creditscore (Loan Application > Credit Score) and open it
5. Set Read: Allowed, Create: Not Allowed, Update: Not Allowed
6. Save

Step 3: Create the "Credit Analyst Full Access" Profile

Repeat Step 2 with profile name Credit Analyst Full Access, but configure the field permission as:

• Read: Allowed, Create: Allowed, Update: Allowed

Step 4: Associate Profiles with Security Roles

1. Open Loan Officer Credit Access profile
2. Go to Security Roles tab → Add your Loan Officer security role
3. Open Credit Analyst Full Access profile
4. Go to Security Roles tab → Add your Credit Analyst security role

Step 5: Verify Access

Test as three different users:

• A Customer Service Rep (no profile): should see **** in the Credit Score field
• A Loan Officer (Loan Officer Credit Access profile): should see the actual credit score value; editing the field should be blocked
• A Credit Analyst (Credit Analyst Full Access profile): should see and be able to edit the credit score

Also test via the API using each user's credentials:

GET https://yourorg.crm.dynamics.com/api/data/v9.2/cr8b1_loanapplications(GUID)?$select=cr8b1_creditscore

Verify that the Customer Service Rep response omits cr8b1_creditscore from the JSON payload entirely.

Step 6: Verify in a View

Add Credit Score to the All Loan Applications view. Log in as a Customer Service Rep and observe that the column appears in the grid header but all cells are blank (not asterisked — this is the view behavior).

---

Common Mistakes & Troubleshooting

Mistake 1: Granting a Profile to a Default Team

Symptom: Everyone in the environment can suddenly read a secured column.

Cause: A column security profile was assigned to the root business unit's default team, which includes all users.

Fix: In Power Platform Admin Center, open the profile and remove the default team from the Teams tab. Add only the specific, deliberately-scoped teams you intend.

Mistake 2: Service Account Missing a Profile

Symptom: A Power Automate flow returns null or empty values for a secured column in its "Get record" action, even though the column clearly has data.

Cause: The service account or flow connection user lacks a Column Security Profile granting read on the column.

Fix: Create or identify the appropriate profile for the integration, and assign it directly to the application user record, or add the app user to a team that has the profile assigned.

Mistake 3: Forgetting to Secure Derived Columns

Symptom: Users who cannot see the Annual Salary column can compute it from a visible formula column.

Cause: A formula or rollup column was built from the secured column but was not itself secured.

Fix: Enable column security on the derived column and assign appropriate profiles, or redesign the formula to not expose the sensitive value.

Mistake 4: Creating Duplicate Profiles for the Same Function

Symptom: Profile sprawl — 40+ profiles that no one can explain, some granting overlapping permissions.

Cause: Profiles were created ad hoc without a naming or design convention.

Fix: Audit your profiles using a FetchXML query against FieldSecurityProfile and FieldPermission. Consolidate redundant profiles and document the intended assignment matrix.

<fetch>
  <entity name="fieldsecurityprofile">
    <attribute name="name" />
    <attribute name="fieldsecurityprofileid" />
    <link-entity name="fieldpermission" from="fieldsecurityprofileid" to="fieldsecurityprofileid" alias="fp">
      <attribute name="entityname" />
      <attribute name="attributelogicalname" />
      <attribute name="canread" />
      <attribute name="cancreate" />
      <attribute name="canupdate" />
    </link-entity>
  </entity>
</fetch>

Run this in XrmToolBox's FetchXML Builder or via the API to get a complete picture of your current configuration.

Mistake 5: Removing Column Security from a Column Without Cleaning Up Profiles

Symptom: After disabling column security on a column, you still have orphaned FieldPermission records in your profiles, and the permission editing UI shows columns that no longer exist as secured.

Cause: Disabling column security on a column removes the security enforcement, but existing FieldPermission records for that column in all profiles remain in the database.

Fix: After disabling column security on a column, do a FetchXML query for all FieldPermission records where attributelogicalname matches the column you just unsecured, and delete them. This is housekeeping that the platform doesn't do automatically.

Mistake 6: Expecting Column Security to Work in Offline Mode

Symptom: Users in offline-enabled apps (using the mobile app offline feature) can see secured column values they shouldn't be able to access.

Cause: Column security enforcement depends on server-side evaluation. In offline mode, cached data may include secured field values that were cached when the user had a different profile, or the offline cache may not consistently apply column security.

Fix: For highly sensitive columns, evaluate whether those tables should be enabled for offline sync at all. If they must be offline-available, ensure the offline data profile is scoped appropriately and test thoroughly.

---

Summary & Next Steps

Column security profiles are one of the most powerful and most underused security capabilities in Dataverse. The core principle to carry forward is the two-layer model: table security controls record access, column security controls field-level access within records that you can already see. Neither layer substitutes for the other.

The key operational decisions you now know how to make are:

• Enable column security on sensitive columns in the column editor before users ever encounter that data
• Design profiles around job functions, not tables or individual users — this gives you maintainable governance at scale
• Use the additive grant model to your advantage: grant narrowly, test thoroughly, and never assign permissive profiles to broad teams or default business unit teams
• Account for API and integration contexts — silent field omission on reads and hard failures on writes require tested service account configurations
• Pair column security with auditing for any regulated data scenario — access restriction alone is not compliance
• Plan for ALM — profile definitions travel in solutions, but assignments need deliberate post-deployment configuration

From here, your natural next areas to explore are the broader record-sharing model (how sharing allows ad-hoc access that also works alongside column security), and the audit and compliance configuration that gives you observability into your security posture. For the record-sharing side, Column-Level Security and Record Sharing in Dataverse covers the complementary sharing mechanisms in depth. For auditing configuration, Configuring Dataverse Auditing and Field-Level Change History in Model-Driven Apps walks through the full audit pipeline.

If you're working through the broader model-driven app security picture, Model-Driven App Security: Configuring Security Roles, Field Permissions, and Team-Based Access for Table Data provides the complete table-privilege layer that column security sits on top of — essential reading for anyone designing a production-grade security model.

Column security done well is invisible to users who have the access they need and unambiguous to users who don't. Getting there requires care in design, discipline in governance, and genuine understanding of the architecture. You now have all three.