Filtered view record ownership

Status: Public Preview — behaviour may change.

What it does

A fourth record-ownership type alongside User/Team, Business Unit and Organization-owned. A filtered-ownership table has no record owner at all: instead, security roles grant CRUD privileges against record filters — saved FetchXML predicates such as City equals Redmond — so a user's access to a row depends on whether it matches a filter their role was granted, not on who owns it or which business unit it sits in.

Key facts

Ownership is chosen when you create the table (Record ownership = Filtered (preview)) and can't be changed afterwards — you can't convert an existing User/Team or Organization-owned table to filtered, or back.
A filtered table gets a system-generated All records entity record filter, granted to System Administrator by default, so admins always have a way in even if every other filter is scoped narrowly.
The filter itself is FetchXML. You build it visually with Edit the view with advanced filter queries, then download the FetchXML and paste it into a Record Filter record — there's no direct designer-to-role path.
An Entity Record Filter is what actually activates a Record Filter against a specific table (by logical name); one Record Filter can back several Entity Record Filters if you want the same predicate reused.
Security roles grant Create, Read, Write, Delete, Append and Append To against a specific Entity Record Filter, not against the table generally — so two roles can see completely different slices of the same table with no shared "base" privilege.
Requires the System Administrator role to create or assign these filtered structures. There's no lighter-weight delegated admin path in preview.
Dataverse Search's link-entity queries only return results from the primary table when a filtered ownership table is on either side of the relationship — a linked Account-to-Contact search won't surface the Contact-side fields if either table is filtered.

When to use / skip

Reach for this when access genuinely depends on a data attribute rather than on who created or was assigned the record — regional data segregation by a postcode or territory field, or department-scoped reference data with no natural "owner". Skip it for anything with a real owner: cases, opportunities, activities — those still want User/Team ownership with sharing, hierarchy security or business units doing the segregation. Filtered ownership rows can't be shared or assigned to a person, so any workflow that expects an owner (approvals routed to a record's owner, "my records" views) breaks outright.

Configuration decisions

How granular to make the filters. One filter per city is easy to reason about but multiplies the number of Entity Record Filters and roles to maintain; a single filter with an IN clause across several values is fewer moving parts but coarser control.
Whether existing views' logic can be reused as-is, or whether the filter needs different conditions than what users see day to day — the Record Filter and the table's default view are two separate things and will drift if nobody owns keeping them aligned.
Where the FetchXML lives operationally: treat the exported FetchXML as source-controlled configuration, not something someone hand-edits in Notepad each environment.
Query performance: filter permissions are evaluated on every query, so a data model with several stacked filters per table needs testing under real volumes before go-live, not after.

Gotchas

No record owner means no sharing and no assignment — if a business process assumes either, it silently stops working on this table rather than erroring clearly.
Forgetting to grant the All records filter to anyone but System Administrator locks out your own support or delegated-admin staff; there's no way to widen access after the fact except by adding a filter and a role.
The ownership choice is permanent per table. Getting the model wrong means creating a new table and migrating data, not flipping a setting.
External virtual tables can't use filter permissions at all — don't design around it for a source you don't control natively in Dataverse.

Consultant notes

Model the record filters before you touch the maker UI — write out, in plain English, "who can see what and why" per table, then translate to FetchXML. Reverse-engineering business rules from a pile of Entity Record Filters after the fact is miserable.
In discovery, ask explicitly whether any of the "no natural owner" tables the client wants filtered-owned will ever need sharing, assignment or an approval routed to "the owner" — that's the question that catches this at the worst time otherwise, mid-build.
Preview status matters here more than most: this changes your security model in a way that isn't reversible per table, so don't commit a client's core data model to it until GA, unless the segregation problem it solves has no workable fallback.
Budget real time for filter-performance testing at expected row counts before sign-off — a filter that's fine on 10,000 test rows can behave very differently on the client's actual data volume.

Worth revisiting at GA, and again if Microsoft adds a supported way to change ownership type post-creation.