The Security User & Row-Level Security

Alongside the Integration User, CRM Analytics ships a second special account: the Security User. It has a narrow but important job, and — like the Integration User — you must never delete it. This lesson explains its two roles and uses them to introduce one of the platform's most powerful ideas: row-level security.

The Security User's two jobs

The Security User exists to do exactly two things:

The second job is the one worth understanding deeply, because it is what makes row-level security work.

What row-level security actually is

Imagine two people open the exact same dashboard at the same moment. I run it and see 1,000 rows; you run it and see 2,000 rows. Nothing about the dashboard changed — what changed is who is running it. That is row-level security: the platform filters the rows of a dataset per user, based on who they are.

The mechanism behind it is a security predicate — a filter rule attached to a dataset that is evaluated at query time against the running user. A predicate can say things like "show only rows where the record's owner equals the running user" or "show only rows for the running user's region." Because it runs at query time, the same dataset serves different slices to different people automatically.

Where the Security User comes in

To evaluate a predicate, CRM Analytics has to read attributes about the running user — their user id, role, region, team, or any other field on the User object. It reads those fields as the Security User. That is precisely why the Security User needs access to the User object: it is the account that looks up "who is this person and what are their attributes?" so the predicate can filter accordingly.

The custom User field gotcha

You can build a predicate on any field on the User object — standard fields like UserId and Role, or your own custom User fields (say, a custom Region__c or Team__c). But there is a catch that mirrors the Integration User's:

Two special users, one pattern

Notice the symmetry across this lesson and the last. Both the Integration User and the Security User are system accounts you must keep alive, and both share the same custom-field gotcha: standard fields work automatically, but custom fields need explicit read access. Internalize that pattern and two whole categories of setup bugs disappear.

Next we look at the org-level Analytics settings that switch features on and off — and how to get a free org to practice in.