The logic behind row-level security. Written as an inline TVF, it yields a row only when the user should see or change the data; tables are bound to it through a security policy, which applies it either to filter rows out or to block writes.
Read more: Microsoft Learn
In the Ultra Transcenders books
Each book explains Predicate function in context, with comparison tables and the common traps.
Terms in this definition
- RLS
Row-level security: filtering the data each person can see down to permitted rows. Power BI models apply it through DAX rules on roles, which bind just Viewers and anyone holding Read or Build; Fabric Warehouse instead uses a T-SQL policy that calls a predicate function.
- Inline table-valued function
A single SELECT statement packaged as a T-SQL function that returns rows. Fabric Warehouse and SQL analytics endpoints use one as the filter predicate when CREATE SECURITY POLICY sets up row-level security on a table.
- Chat message roles
Labels on chat messages: instructions go under system, the person's input under user, the model's previous answers under assistant, and results returned by a called tool under tool (or function).
- Security policy
Implements row-level security for Fabric warehouses or SQL analytics endpoints by attaching an inline table-valued function, acting as filter predicate, onto a table. Excluded rows vanish quietly from reads, updates and deletes.
- FILTER
Returns just those rows of a table that meet a condition. In CALCULATE it handles conditions too complex for a Boolean filter argument, though a Boolean filter is faster whenever one will work.
Related terms
- SCHEMABINDING
Locks an object to the schemas it depends on. Security policies default to ON, meaning nobody's rights on their predicate function get checked; turned OFF, each user requires SELECT or EXECUTE over that function plus anything it touches.