Dataverse Filter-Based Security Preview: Column Filters, Ownership Models and Permission Pitfalls

For Power Platform administrators, the most important detail is not the filter syntax. It is what happens to existing permissions. On user/team-owned and organization-owned tables, filter privileges add access; they do not subtract access already granted elsewhere. A regional filter is therefore not a universal fence around the data. Getting that distinction right separates useful governance from an unexpectedly generous permissions model.

What is changing—and what the dates mean​

Roadmap item 577860, titled “Secure Dataverse record with column-based filtering,” describes attribute-driven record security for scenarios including reporting and aggregated datasets. Its roadmap metadata lists development status, an October 2026 preview target, and January 2027 general availability, scoped to the web platform and Worldwide Standard Multi-Tenant cloud. These are planning details, not confirmation that every environment has received the feature; Microsoft explicitly describes roadmap dates as estimates subject to change.

There is also evidence of an earlier scheduling change. Microsoft’s 2026 release wave 1 change history records that this feature was removed from that release plan on August 25, 2026, because it moved to a future wave. That entry explains the schedule’s history; it does not establish a replacement release date.

The operationally useful status is the preview designation in Microsoft Learn. Its filter-based security documentation, updated October 1, 2026, warns that preview functionality may be restricted and is not intended for production use. January 2027 should therefore remain a planning target rather than a production deployment deadline. The documentation’s update date is not itself a tenant rollout date.

Column-based filtering is row security, not field masking​

The terminology deserves unpacking. A filter might examine a City column and authorize access to rows where its value is Redmond. The column supplies the condition; the resulting permission concerns the record. Microsoft’s examples also cover territory, department, data classification, and entitlement-based access.

That differs from column-level security, which controls access to particular fields within records—for example, whether a user can read or update a sensitive identifier. Microsoft documents column security profiles and optional masking as separate controls. A geographic row filter does not automatically hide sensitive fields in the rows it permits.

Microsoft’s security architecture guidance makes the layering explicit: a column security profile does not grant access to the underlying record. The user must already have record access before the profile can authorize access to secured columns. Administrators may need both mechanisms, but they answer different questions: “Which records?” and “Which values inside those records?”

Nor is this merely a cleaner-looking application view. Microsoft’s filtered-ownership documentation says create, read, update, and delete calls are secured against the applicable filter privileges. Using a view editor to construct the filter is an authoring convenience; creating the security objects and assigning their privileges is what establishes authorization.

Three ownership models, three different implications​

Microsoft supports filter-based security across three table ownership types. Choosing among them is an architectural decision, not a cosmetic setting.

Microsoft’s ownership comparison supports these distinctions, including the exclusive role of filters in filtered-ownership tables.

For an existing sales application, keeping user/team ownership may be appropriate: salespeople retain their own opportunities while a territory filter grants access to additional records. Assignment, sharing, and business-unit hierarchy access continue to work. The filter supplements that model rather than replacing it.

Filtered ownership is a different proposition. Records have no owner and cannot be assigned or shared with users or teams. A Created by field still identifies the creator, but creation does not establish ownership. Microsoft also creates an All records filter privilege and grants it to the System Administrator role.

The practical conclusion is straightforward: choose filtered ownership when business attributes should determine access, but retain conventional ownership when assignment and sharing are genuine workflow requirements. Removing artificial ownership can simplify a design; removing meaningful ownership can break its assumptions.

How the authorization components fit together​

The configuration has four connected parts:

• Record Filter: stores the FetchXML definition identifying qualifying records.
• Entity Record Filter: associates that definition with a Dataverse table.
• Filter privilege: authorizes a particular operation against the matching records.
• Security role: distributes those privileges to users or teams.

Dataverse evaluates authorized filters from users’ roles and team memberships. A record matching an authorized filter receives the corresponding operation permission.

Supported operations are Create, Read, Write, Delete, Append, and Append To. They need not be granted as a bundle. Microsoft illustrates a configuration with Read, Write, and Delete for Redmond records, but only Read for Seattle and Bellevue records.

This makes the feature more flexible than a single visibility switch. However, administrators must assess the combined result: adding another role or team membership can supply another authorized filter. A beautifully narrow filter does little good if a second permission opens the whole table.

A documented preview setup, step by step​

The following sequence follows Microsoft’s filtered record ownership procedure. Use a nonproduction environment for evaluation. Microsoft requires the System Administrator security role to create and assign the roles used by this feature, and its preview warning remains applicable throughout.

1. Create a filtered-ownership table​

In Power Apps:

1. Select the intended environment.
2. Open Solutions, then open an existing solution or create one.
3. Select New table, followed by Table (advanced properties).
4. Enter the table’s display name.
5. Set Record ownership to Filtered (preview).
6. Save the table and add sample rows for testing.

These are the documented preview labels and sequence. Microsoft also states that a table’s ownership type cannot be changed after creation, so this should not be approached as an in-place conversion of an existing organization-owned table.

2. Define which records qualify​

Microsoft supports authoring the filter in FetchXML. Its alternative procedure uses the model-driven app’s filter interface:

1. Open the model-driven app for editing and open the relevant table.
2. Select Filters on the action bar.
3. Adjust existing conditions and use + Add to add the required condition, such as City equals Redmond.
4. Select Download FetchXML.
5. Open the downloaded file in Notepad.

Use conditions that reflect the intended business rule, and inspect the generated definition before making it part of a security configuration.

3. Store the Record Filter​

Return to the solution and select + New → More → Other → Record Filter. Supply a unique name with a prefix and a descriptive display name. Paste the FetchXML into the FetchXML box, then select Save & close. This stores the predicate; it does not finish the role assignment.

4. Associate the filter with its table​

In the solution, select + New → More → Other → EntityRecordFilter. Enter a name, select the Record Filter, and set Related Entity to the table’s logical name. Save and close the entry.

The logical-name detail matters: Microsoft’s example uses account, rather than the table’s display label. Multiple filters can be associated with the same table through separate entries.

5. Grant the operation and assign the role​

Open the intended security role, select the target table, choose the filter privilege, and grant the required operation. Then assign the role to the intended users or teams. For an initial read-only evaluation, Microsoft’s example grants Read permission for the Redmond filter.

6. Validate as an ordinary user​

Microsoft’s example expects a user with only the relevant Redmond Read grant to see the matching records, while the administrator can see all records through the global privilege. Consequently, testing only with the configuration administrator is inadequate: that account deliberately has broader access.

A sensible acceptance test is to include both matching and nonmatching rows, confirm the expected visibility under a nonadministrator account, and attempt operations that were not granted. These are recommended validation checks, not claims of firsthand testing.

Troubleshooting the common mismatches​

When an evaluation produces unexpected access, follow the documented authorization chain rather than repeatedly editing the application view.

The user sees too many records. Review every assigned role and team membership. On user/team-owned tables, also examine ownership and sharing. On organization-owned tables, check for standard privileges granting access to all rows. Filter privileges do not revoke those broader permissions.

The user sees no expected records. Verify the stored FetchXML, its association through Entity Record Filter, the target table, the required operation privilege, and the role assignment. These checks follow directly from Microsoft’s component model: a correct predicate alone is not a complete authorization configuration.

An administrator sees everything. That is expected for a newly created filtered-ownership table because the System Administrator role receives the global privilege. Repeat the test with the intended user permissions before concluding that the filter is ineffective.

Sensitive fields remain visible. Row filtering is not field protection. Review the separate column-level security configuration where the requirement concerns individual values rather than entire records.

Limits that matter before adoption​

Microsoft documents several boundaries that deserve a place in the evaluation plan:

• External virtual tables are not currently supported for filter permissions.
• Ownership type cannot be changed after table creation.
• Every query applies filter permissions, so data-model and filter design affect performance.
• For filters involving a link-entity relationship, Dataverse Search returns results from the primary table without including values from the linked table.

The performance caveat qualifies the roadmap’s scalability appeal. Reducing artificial ownership or complicated sharing arrangements may simplify administration, but that is not evidence that every filtered query will run faster. Microsoft advises efficient modeling and filter design; the inspected documentation supplies no universal performance improvement or benchmark.

For evaluation, measure representative queries and test the actual relationship patterns your application uses. Also inspect the quality of the attributes driving access. As an architectural inference, if a department value determines authorization, incorrect department data becomes a security concern rather than merely a reporting nuisance. That follows from the documented attribute-based access model.

The practical takeaway​

Dataverse filter-based security gives administrators a useful additional way to express business permissions. It can augment existing ownership or, with filtered ownership, make record attributes the exclusive basis for access. Those are distinct deployment choices with different consequences for sharing, assignment, and effective permissions.

The right next step is a controlled preview evaluation: choose the ownership model deliberately, build the full filter-to-role configuration, test with nonadministrator identities, and examine overlapping privileges and query behavior. Treat the January 2027 roadmap target as provisional and the documented preview restriction as operative.

The governing principle is simple enough to put on the test plan: a filter can grant access without being a rule that denies everything else. That is the detail administrators should settle before the first regional dataset goes anywhere near production.