Dataverse record filters are already in the platform
Microsoft announced column-based record filtering in MC1465569, a week after removing it from the release plan. The mechanism already ships as a fifth privilege depth, and every environment we checked carries two filtered grants from Microsoft.
MC1465569 describes a way to secure records by column values instead of by ownership. An admin defines a filter, attaches it to a security role, and the role reaches only the records that match. The notice is for awareness and asks for no action.
The dates around it do not agree. Microsoft's 2026 release wave 1 change history lists “Secure Dataverse record with column-based filtering” as removed on August 25, 2026, moved to a future release wave. The message center notice followed on September 1. This guide does not predict when the feature reaches preview. It covers what is already in the metadata, which you can check today.
What a record filter is
Every privilege a security role grants has a depth. Four are familiar. Basic reaches records the user owns or that were shared with them, Local reaches the user's business unit, Deep reaches that unit and the units below it, and Global reaches the whole organization.
Dataverse has a fifth. Microsoft's Web API reference lists RecordFilteras a privilege depth, described as privileges “determined by associated RecordFilter.” A grant at this depth does not reach a fixed slice of the organization. It reaches whatever records a filter matches.
Three tables hold it:
roleprivilegesis the grant. Itsrecordfilteridcolumn points at the filter, and itsprivilegedepthmaskis 16. The four familiar depths store 1, 2, 4 and 8.recordfilteris the filter. Itsfetchxmlcolumn holds the condition a record has to meet.entityrecordfilterbinds a filter to the table it constrains.
A filtered grant sits nowhere on the Basic to Global ladder. Depending on its filter, it can reach fewer records than Basic, records the user never owned and nobody shared, or everything Global would.
What is already there
For this guide, Pathix checked three Dataverse environments by reading their security metadata over the Web API: two created in April from the same provisioning image, and a Developer environment created in September, in a different region, from a newer image. All three are in one tenant. All three carry the same thing:
- Three record filters, all managed and active.
msft_Global, displayed as All Records, which has no FetchXML at all.- Two filters on the
skilltable,SkillRoleFilterandSkillRoleEditFilter. - Two grants at the filtered depth, Read and Write on
skill, both on a Microsoft role named Skill Sharing Role.
The filters come from two hidden Microsoft solutions, msft_AuthorizationData and msdyn_RelevanceSearch. There is no feature to install and no setting to turn on. In every environment checked, those solutions report install dates earlier than the environment itself, which is what you see when a component ships in the image environments are provisioned from.
The sequence, every date readable from metadata or from Microsoft's published change history:
- April 2, 2026:
msft_Globalis present in the April provisioning image. - August 6 and 7, 2026: the two skill filters arrive in environments built from that image.
- August 25, 2026: column-based filtering is removed from the release plan.
- September 1, 2026: MC1465569 announces it.
- September 11, 2026: the skill filters are already inside the newer image.
None of this is a vulnerability. In all three environments Skill Sharing Role has no users and no teams, so today those two grants reach nobody. The point is narrower and more durable: the privilege depth, the value every access review reads, no longer tells you what a grant reaches on its own.
Why a filtered grant is hard to read
The example in Microsoft's announcement is a simple column comparison: a user reaches records where City is Redmond. The filters that actually ship are not that simple.
SkillRoleFilter starts at skill and joins through the security roles mapped to each skill, the users and teams that hold those roles, and team membership, then ends on a condition that matches whoever is running the query. It reads the security model to decide access to records. Which rows a given person reaches is settled when that person queries, not when the role is configured.
So there are three levels of answer, and an access review should say which one it gives:
- That a grant is filtered. The depth mask says so.
- What the filter keys off. Its FetchXML names the tables and columns involved.
- Which records a particular person reaches. That depends on the data and on who is asking, so only running the query as that person settles it.
Anything that decodes privilegedepthmaskas four values has no case for 16, and whatever it falls back to is wrong. It either calls the grant no access or calls it broader than it is. If you maintain an access report or a script that reads role privileges, add the case now, while the only filtered grants in sight are Microsoft's.
How to check an environment
You need an account that can read security roles, such as a System Administrator. In a browser tab signed in to the environment, each request below is a URL you can paste. Replace yourorgwith your organization's address.
Grants at the filtered depth
The lookup to the filter cannot be used in a filter expression, so the request filters on the depth mask instead, and selects the lookup as _recordfilterid_value. In every environment we checked, this returns two rows. More than two means a filter has been attached to another grant, by someone in your organization or by a later Microsoft update, and that filter is worth reading.
To turn each row into names:
The filters themselves
fetchxml is the condition. An empty one, like msft_Global, does not constrain anything. ismanaged and createdon tell you whether a filter arrived in a managed solution and when it appeared.
Which table each filter constrains
Each row ties a filter to a table by object type code. Match the code against the table's metadata to get its name.
Who holds the role
A filtered grant matters only if someone holds the role. Check its members the way you would for any role, and include teams: a user can hold a role through a team without appearing on the role directly. The integration account guide has the FetchXML for both routes.
Writing record filters. The feature is out of the release plan, and building access control on it now means building on something Microsoft has already moved once. Checking for filters works the same whenever it ships.
What Pathix reports
Pathix reads every role privilege on each scan. Until September 17, 2026, it read this depth wrong: it mapped mask 16 to no access, so the two Microsoft grants showed as not granted. That understated them, and it is exactly the kind of silent wrong answer this guide is about.
A grant at this depth now shows as Filtered. It ranks below Basic, because a reach nobody has measured cannot honestly outrank one that is known, and it is never counted as Global or dropped from an answer. Any answer that includes a filtered grant carries a note that its reach is unknown, including answers given to AI agents through the Pathix MCP server. When a grant's depth changes between scans, the change is recorded, so a filter attached to an existing grant shows up as a change.
Pathix does not yet read the filter or the table it is bound to, so it can tell you that a grant is filtered but not what the filter keys off. Which records a filter reaches depends on record data, and Pathix reads metadata only, so that last question stays with Dataverse.
How Pathix resolves roles, teams and effective access →