Row-Level Security

Decide which rows a given reader is allowed to see at all.

Where column masking controls whether a reader sees the real value in a field, row-level rules control whether the row reaches them in the first place. A regional manager opening a company-wide report sees only their own region's rows — and the totals reflect that, because the restriction is applied in the query.

ℹ️ Same Machinery, Different Verb Row-level rules are configured exactly like column masking rules — same condition types, same operators, same precedence. The only difference is what the rule decides: instead of a masking level, it chooses HIDE ROW or SHOW ROW.

Rule Outcomes

Setting	Effect when the rule matches
SHOW ROW	Rows meeting the rule's conditions are visible to that reader.
HIDE ROW	Rows meeting the conditions are removed from the result entirely.

Writing a Rule

Each rule selects the users it applies to using the same four condition types as column masking:

PersivX User Email
PersivX User Id
PersivX User Attribute
PersivX User Group

With operators is one of, is not one of, and Equals Column Value. A rule may also carry a column value condition naming the object, attribute, and values it restricts on.

The Most Useful Pattern

Equals Column Value is what makes row-level security scale. Rather than writing a rule per person, point the rule at a column that holds the owning user's email — an account_owner or assigned_to field — and PersivX compares it against whoever is signed in. One rule then covers every user, and stays correct as the data changes.

The same applies to user attributes: match a Region attribute against a region column and one rule serves every region.

Precedence

Row-level rules resolve in the same order as masking rules:

User-level rules (email or id)
Attribute-level rules
Group-level rules
The default, if nothing matched

Within a level, the more specific rule wins, and remaining ties go to the first match in list order. Rules can be dragged to reorder.

Testing

Save the rules, then use Test for user to evaluate them as a specific person. Each rule is marked PASS or FAIL so you can confirm which one is deciding the outcome before anyone else sees the report.

⚠️ Check the Totals, Not Just the Rows Because rows are removed before aggregation, a restricted reader sees different totals, averages, and counts from an unrestricted one. That is usually the intent — but confirm it is what you want before publishing, particularly on reports where a figure is quoted elsewhere.

💡 Public Reports A report built on row-level-restricted data needs a signed-in user for the rules to have anyone to evaluate against. See Protected Dashboard in Report Settings.