The Dataset Starts with Everything

Module 7 of 8 in the chapter Files, Folders, Reports and Other Data, chapter 12 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: CRM Analytics copies Salesforce data into datasets of its own. Who sees which rows of that copy?

Module 4 ended with a static dashboard: one running user’s access, shown to everyone who opens it. CRM Analytics is the same idea, bigger. It doesn’t read your records when someone opens a dashboard. It copies them, ahead of time, into a dataset. And the copy is made by a user who can see everything.

“Because the Integration User has View All Data access, consider restricting access to particular objects and fields that contain sensitive data” (Salesforce Data Access in CRM Analytics (opens in a new tab), Salesforce Help, checked 2026-11-07).

So the dataset starts with everything. All the sharing you built in chapters 6 to 11 decided who sees each record in Salesforce. None of it came along with the copy. What comes along is up to you.

Two questions again

Module 1’s two questions work here too.

Who can open the container? In CRM Analytics, the container is the app. “CRM Analytics apps are like folders, allowing users to organize their own data projects—both private and shared—and control sharing of dataset, lenses, and dashboard.” To let someone see a dashboard or a dataset, “one way to share is by sharing the app it’s in” (Create and Share CRM Analytics Apps (opens in a new tab), Salesforce Help, checked 2026-11-07). Apps are shared at levels you’ll recognize from report folders: Viewer, Editor and Manager.

Whose access fills it? Nobody’s, unless you add it. Salesforce says it as a warning: “If row-level security isn’t applied to a dataset, any user that has access to the dataset can view all records in the dataset” (Add Row-Level Security with a Security Predicate (opens in a new tab), Salesforce Help, checked 2026-11-07).

Read that twice. In Salesforce, forgetting a sharing rule means someone sees too little. In CRM Analytics, forgetting row-level security means everyone with the app sees everything.

Row-level security, two ways

There are two ways to put rows back behind a lock.

Sharing inheritance. “Use sharing inheritance to let CRM Analytics apply the same sharing setup for your datasets as Salesforce uses for your objects.” It brings the whole model across: “manual and rule-based sharing as well as role hierarchy, role, group, apex-managed, and team-based sharing.” And “Sharing inheritance is on by default in new Salesforce orgs.” The cost: “an increase in the time to complete data syncs, dataflow and recipe jobs, and queries. The more complicated the sharing settings, the more impact there is” (Add Row-Level Security by Inheriting Sharing Rules (opens in a new tab), Salesforce Help, checked 2026-11-07).

A security predicate. “A security predicate is a filter condition that defines row-level access to records in a dataset.” You write the rule yourself, based on a column in the dataset and who the user is. Salesforce lists what it can model: record ownership, management visibility through the role hierarchy, territory assignments, team or account collaboration, or a combination (Add Row-Level Security with a Security Predicate).

Click to enlarge

Sharing inheritance sounds like the answer to everything. Read its limits before you rely on it (Sharing Inheritance Limits and Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07):

Five objects. “Supported objects for sharing inheritance are: Account, Case, Contact, Lead, Opportunity.” Custom objects aren’t on the list.
One object per dataset. “A dataset can inherit sharing settings from only one object, regardless of how many source objects are used to create the dataset.” Join opportunities to a custom object, inherit from Opportunity, and the custom object’s rows ride along on the opportunity’s sharing.
Not too many grants. It works “if all object records have fewer than 400 sharing descriptors each,” and it covers a user “if they have ‘View All Data’ permission or their record access is granted by fewer than 3,000 sharing descriptors.” A sharing descriptor is access through owning the record, the role hierarchy, sharing rules, manual sharing or Apex managed sharing.
Salesforce users only. “It isn’t available for Experience Cloud Sites users and logins. To provide security in Experience Cloud Sites, you must use security predicates.”
Users it can’t cover see nothing, unless you say otherwise. “Without a security predicate, users not covered by sharing inheritance see no data in the dataset.” So set a backup predicate. The default when sharing is on is the safe one: “you can set the security predicate to ‘false’ to block all users not covered by sharing” (Add Row-Level Security with a Security Predicate).

And three that leak, in Salesforce’s own words, under “Information Leak Considerations”: “The computeRelative and delta dataflow transformations can merge information from records with different security.” “Calculated fields are treated as normal fields. Row-level security applied during the calculation in Salesforce is ignored.” And “If your dataflow doesn’t do a full extraction each time it runs, evaluate whether security drift is a risk.” The dataset is a copy, and a copy is only as current as its last sync (Sharing Inheritance Limits and Considerations).

Test knowledge. Know that CRM Analytics loads data as the Integration User, with View All Data, and that a dataset with no row-level security shows every record to anyone who can open it. Know the two kinds of row-level security, sharing inheritance and security predicates. Know that sharing inheritance comes from one object per dataset, from Account, Case, Contact, Lead or Opportunity, that it’s for Salesforce users only, and that Experience Cloud sites need predicates. Know to set a backup predicate, usually false. A likely area, not a known question.

What an architect decides here

Which objects and fields the Integration User is allowed to load at all.
For each dataset: sharing inheritance, a predicate, or both, and the one object it inherits from.
The backup predicate for users sharing inheritance can’t cover.
For datasets that join several objects, whether one object’s sharing is right for all their rows.
Which apps are shared with whom, at Viewer, Editor or Manager.
How often datasets fully sync, so security doesn’t drift from Salesforce.
For any site users, the predicates that keep them to their own rows.

Beyond the exam: what AI changes. CRM Analytics is where many orgs keep their numbers, and agents are being asked for numbers: “What’s our pipeline by region?” An agent that reads a dataset gets what the dataset’s row-level security allows its user, and a dataset with none gives it everything. Before you point an agent at analytics, check every dataset it can reach for row-level security. Chapter 20 covers agents.

Explore

Salesforce Data Access in CRM Analytics (opens in a new tab), Salesforce Help (checked 2026-11-07)
Add Row-Level Security by Inheriting Sharing Rules (opens in a new tab), Salesforce Help (checked 2026-11-07)
Sharing Inheritance Limits and Considerations (opens in a new tab), Salesforce Help (checked 2026-11-07)
Add Row-Level Security with a Security Predicate (opens in a new tab), Salesforce Help (checked 2026-11-07)
Create and Share CRM Analytics Apps to Give Business Users a Big Data Picture (opens in a new tab), Salesforce Help (checked 2026-11-07)