CRM Analytics. Row-level security. Keep territory pipeline inside the fence.

What this means for your store

Without row-level security, any rep with app access can query every opportunity in Explore. That is a problem when UK field sales and US inside reps share one Salesforce org and partner-led ecommerce deals carry sensitive margin fields. RLS predicates filter rows after load - typically on $User.Id, role trees, or a territory mapping dataset synced from Salesforce.

Scenario on a real storefront

A multinational B2B marketplace restricts opportunity_grain so reps only see deals they own or sit on as team members:

# Dataset → Security Predicate

# Option A - ownership (security UI)
'OwnerId' == "$User.Id"
  || 'TeamMemberId' == "$User.Id"

# Option B - territory dataset "user_territory"
# Columns: UserId, TerritoryCode
# Fact column: TerritoryCode
'TerritoryCode' in {
    var userTerr = load "user_territory";
    userTerr = filter userTerr by 'UserId' == "$User.Id";
    userTerr = foreach userTerr generate 'TerritoryCode' as 'TerritoryCode';
    ...
};

# Verify: login as test rep → Explore → row count << admin

What to do next

• RLS lives on the dataset, not the lens - predicate edits need an owner on sales ops; document who can approve changes.
• Embedded analytics service accounts need their own RLS profile or they inherit either zero rows or an admin's full org view.
• Managers need roll-up visibility - use role-hierarchy predicates or a separate leadership dataset; disabling RLS is not the shortcut.

Bottom line

Row-level security keeps pipeline and account revenue inside the right territory. Predicate on owner, team, or territory keys, then verify with rep test users before wide rollout.