N/A monogram← vibes
Dataverse / reference

Dataverse

Filter-based securityexplained.

Microsoft Learn now calls it filter-based security. The setup guides still say filtered record ownership. Here’s how those names fit Dataverse’s access model.

PREVIEWAI-researched and AI-generated explainer · Prepared at Jukka Niiranen’s direction
Sources checked

Dataverse can grant access based on a record’s city, classification, or related assignment. A filter defines which records match; a security role grants access to them.[1]

A condition becomes a record access grantA filter condition matches records and a security role grants access to the matching records.RECORD CONDITIONCity = RedmondROLE GRANTS READMatching records

The names Microsoft uses

Filter-based security covers the mechanism. Filtered record ownership is a table ownership option that uses it. Filters also work with existing user/team-owned and organization-owned tables.[1]

Filter-based security applies to three ownership modelsFiltered ownership relies on filters for record access. User or team ownership and organization ownership receive filter grants in addition to their existing access.Filter-based securityThe record-access mechanismAPPLIES TOFiltered ownership“Filtered (preview)”Filters determinerecord accessUser/team ownershipRecords retain ownersFilter grants addto existing accessOrganization ownershipNo individual ownerFilter grants addto existing access
Filter-based security
  • Filtered ownership“Filtered (preview)” · Filters determine record access.
  • User/team ownershipRecords retain owners. Filter grants add to existing access.
  • Organization ownershipNo individual owner. Filter grants add to existing access.
Filters work with all three ownership models. Filtered ownership uses filter privileges for all record access.
Filtered record ownership
The ownership choice and the maker/developer guide names.[2]
Filtered view security
The companion maker guide’s term for adding filters to existing tables.[3]
Secure Dataverse record with column-based filtering
The release-plan and Message Center title.[5][7]

Column values decide which records qualify. This differs from column-level security, which protects individual fields. An ordinary saved view is not automatically a security rule: the filter must be registered, bound to a table, and granted through a role.[2][8]

What can Mico actually read?

Each scenario grants Read through a filter that matches non-confidential agreements. Change Mico’s other permissions to see which additional records become accessible. Another grant can give him access to a Confidential agreement.[1]

Mico’s access to six agreements

Filter condition: Classification is not Confidential.

READ ONLY
Compare the table and permission scenarios

Adds the All records filter grant for Read.

Filter grants combine with other grantsThe non-confidential filter grants three records. There are no other grants in the default scenario, so three records are accessible.Filter match3 recordsOther grants0 records∪UNION, NOT SUBTRACTIONEFFECTIVE READ ACCESS3 of 6 records
3 of 6 accessible

Only Standard agreements match the filter. This table has no record owners and no other filter grants.

  • A01Standard

    Redmond

    Filter match
  • A02Standard

    Seattle

    Filter match
  • A03Confidential

    Redmond

    No matching grant
  • A04Confidential

    Seattle

    No matching grant
  • A05Standard

    Bellevue

    Filter match
  • A06Confidential

    Bellevue

    No matching grant

All six fictional records stay visible here so you can inspect their grants. Mico’s application would expose only the accessible records.

These scenarios compare table designs; they do not convert a table’s ownership type. Read does not also grant Create, Write, or Delete.

Default example: filtered ownership · Read
  • A01 — Redmond, Standard — Filter match
  • A02 — Seattle, Standard — Filter match
  • A05 — Bellevue, Standard — Filter match

Three of six records are accessible. The three Confidential records have no matching grant. On an existing table, access to Mico’s own records also grants A04 (four of six). Organization-wide Read grants all six. Another role granting all records also produces six of six in every scenario.

A filter grants permission to matching records.
It does not cancel permission granted elsewhere.

How the filter reaches a security role

The Record Filter stores the FetchXML predicate. EntityRecordFilter connects it to a table. The generated privileges then let a security role grant operations through that filter.[2][4]

Five connections configure filter-based accessOne: Record Filter stores the condition. Two: EntityRecordFilter binds it to the Agreements table. Three: filter privileges define supported operations for that binding. Four: a security role grants Read. Five: a user or team receives the role. These are configuration relationships, not an internal request pipeline.01 / DEFINE02 / BIND03 / GENERATE04 / GRANT05 / ASSIGNRecord FilterEntityRecordFilterFilter privilegesSecurity roleUser or teamClassification isnot ConfidentialThis filter +this tableTable-specificdata operationsGrant Read viathis filterMico receivesthe roleAgreements table
  1. Record FilterFetchXML: Classification is not Confidential.
  2. EntityRecordFilterBinds this filter to this table.↳ Agreements table
  3. Filter privilegesGenerated for the table’s data operations.
  4. Security roleGrants Read through the filter.
  5. User or teamMico receives the role. All grants accumulate.
Supported operationsCreateReadWriteDeleteAppendAppend To
Configuration relationships, not a diagram of Dataverse’s internal request processing. Filters are assigned per operation; grants accumulate across a user’s roles and team memberships.
See a minimal illustrative FetchXML predicate

Replace these fictional logical names and choice values with your table’s metadata. Choose conditions deliberately, including how empty values should behave.

<fetch>
  <entity name="demo_agreement">
    <filter type="and">
      <condition attribute="demo_classification"
                 operator="ne" value="100000001" />
    </filter>
  </entity>
</fetch>

Here, the fictional choice value 100000001 means Confidential. Follow the maker guide or developer guide for the actual configuration.

What changes with table ownership

Adding filters to an existing table preserves its ownership model. Creating a table with filtered ownership removes record owners, assignment, and sharing.[1][3]

Filtered ownership

Filters determine access

Useful when attributes should determine access. Authorized filters combine; the system administrator receives an All records filter.

No record owner. Records cannot be assigned or shared.

User/team ownership

Filters add access

Keep ownership, assignment, sharing, and business-unit access. A filter can grant additional records in a territory or temporary delegation.

It cannot subtract an existing grant.

Organization ownership

Filters add access

Grant matching rows through a filter, but check other roles: a normal table-wide grant still gives table-wide access.

No individual record owner.

Ownership type is fixed at creation. Adding filter privileges to an existing table does not turn it into a filtered-ownership table.[2]

The announcements and the dates

Microsoft has used different names in release plans, setup guides, and announcements. The October concepts page explains how the pieces fit. Support for existing tables was already documented in September.

  1. Filtered views appear in the release plan

    Jukka’s December post quotes “Secure data access using filtered views,” motivated by ownerless reporting records. The historical plan targeted April 2025 preview.

    Historical reporting

  2. The earlier item disappears

    Jukka reports its removal without a change-history entry. This records his observation, not Microsoft’s explanation.

    Historical reporting

The earlier item is a strong capability match. A formal Microsoft statement connecting the full history was not established in this research.

  1. Another removal, under the column-based-filtering name

    The 2026 wave 1 change history removes “Secure Dataverse record with column-based filtering,” moving it to a future release wave.

    Official release-plan history

  2. MC1465569: preview announced for 15 September

    The public message copy uses the column-based-filtering title and announces a September 15 preview. It focuses on field values and ownerless datasets.

    Reproduced announcement

  3. Maker and developer setup guides are published

    Maker and developer guides document filtered ownership. The next day’s companion guide covers filters on existing ownership tables.

    Official documentation

  4. Microsoft adds a filter-based security concepts page

    A new concepts article and navigation split distinguish ownership-based and filter-based security. The existing setup names remain.

    Official documentation

  5. MC1486027: preview announced for 2 October

    A later public copy gives October 2 as the preview date, under the same title. This mirror was published October 3; the original tenant notice was not retrieved.

    Reproduced announcement

Message copies establish announced dates, not verified rollout completion. They do not explain the date change or establish that the later notice formally superseded the earlier one. The historical April 2025 target is preserved in an archived release-plan copy.

What still needs checking

Preview status

The docs still mark this preview and advise against production use. This research did not establish a GA date or feature-specific licensing entitlement.[1][2]

Broader access through other roles

Review all roles and team memberships for the same operation. A broader grant can make a narrower filter irrelevant to the final accessible set.[1]

Queries and table support

Filter permissions apply to every query, so design affects performance. The maker FAQ says virtual tables are not currently supported.[2]

Search and tenant availability

The maker guide documents a linked-table Search limitation. This page does not verify Search compatibility, tenant rollout, or improvements to the configuration UI.[2]

Sources and documentation

The technical explanation follows Microsoft’s public documentation. The history also uses Jukka’s reporting and public copies of Message Center notices.

  1. [1]Filter-based security conceptsMicrosoft Learn · ownership comparison and effective access
  2. [2]Filtered record ownershipMicrosoft Learn · setup, ownership restrictions, and limitations
  3. [3]Filters on existing ownership tablesMicrosoft Learn · supplemental access and related-table examples
  4. [4]Filtered record ownership by using codeMicrosoft Learn · API configuration and cumulative filter access
  5. [5]2026 wave 1 change historyMicrosoft Learn · removal recorded August 25
  6. [6]MC1465569 public reproductionModern Workspace Pro · September 15 preview announcement
  7. [7]MC1486027 public reproductionPUPUWEB · October 2 preview announcement, mirrored October 3
  8. [8]Ownership-based security conceptsMicrosoft Learn · traditional grants and column-level security

Research synthesis, explanatory text, diagrams, and page implementation were generated with AI from the linked sources. Microsoft documentation, reproduced announcements, and Jukka’s reported observations are identified separately. This page does not report a fresh tenant test.

Dataverse icon: MicrosoftCloudLogos