Control Access and Secure Your Data

Learning Objectives

After completing this unit, you’ll be able to:

• Describe CRM Analytics data origins and built-in user accounts.
  
• Compare row-level security and field-level security.
  

Permission Versus Access

In a previous unit, we used an analogy to help you remember the difference between permission set licenses and permission sets. Now here’s a way to differentiate between permissions and access. Think of permissions as what you can do and access as what you can see. These concepts are really what we mean when we talk about security in CRM Analytics.

As the Salesforce admin for DTC, you consider who has access to what—who can view what data. In the previous units, you learned how to grant users permission to use apps and features. Now let’s see how to exercise very granular control over each user’s access to data.

Salesforce Data Access in CRM Analytics

Except when you upload csv files, the data that CRM Analytics uses probably comes from Salesforce. Let’s talk about how CRM Analytics accesses that data on your behalf. Why? Because CRM Analytics uses predefined internal accounts to do its thing. Since Salesforce admins like you maintain profiles and permissions, you need to know what these accounts are and how they’re configured. Here’s the inside scoop.

CRM Analytics accesses Salesforce data based on permissions of two internal CRM Analytics users: Integration User and Security User.

• CRM Analytics uses the permissions of the Integration User to extract data from Salesforce objects and fields when a dataflow job runs.
  
• When you query a dataset that has row-level security based on the User object, CRM Analytics uses the permissions of the Security User to access the User object and its fields.
  

Let’s take a look at your Integration User and Security User profiles and user records.

1. From Setup, enter Users in the Quick Find box.
   
2. Under Users, select Users.
   

In the list, you see the user named "User, Integration", and the user named "User, Security". Click on either to see detailed information about these users.

There are profiles associated with these users too.

1. From Setup, enter Profiles in the Quick Find box.
   
2. Under Users, select Profiles.
   

You’ll see profiles named Analytics Cloud Integration User and Analytics Cloud Security User. Click on either to see the various permissions assigned. For example, look under the heading Field-Level Security to see if any objects you want to query have field-level security applied.

These profiles are often cloned for customized use when you enable CRM Analytics in your org. You or another admin probably did this during enablement.

Row-Level Security

If CRM Analytics users have access to a dataset, they have access to all records in the dataset, by default. Makes sense, right? However, sometimes you want to implement row-level security on a dataset to restrict access to certain records. Why? Some records contain sensitive data that shouldn’t be accessible to everyone.

Security Predicates

To implement row-level security, you set a predicate for each dataset where you want to restrict access to records. Sounds complex, but a predicate is just a fancy name for a filter condition that defines row-level access to records in a dataset. When a user submits a query against a dataset that has a predicate, CRM Analytics checks the predicate to determine which records the user can access. If the user doesn’t have access to a record, CRM Analytics simply doesn’t return it.

Let’s see what a security predicate looks like. Don’t worry. We won’t change any settings, so nothing will break!

You can see security predicates by looking at the dataflow JSON file or the edit page for the dataset.

It’s easier to see the predicate on the dataset edit page.

1. From the App Launcher, find and select Analytics Studio. 
   
2. On the Analytics Studio tab, click Browse and then click All Items.
   
3. Click Datasets.
   
4. Hover over a dataset, click the action arrow, and click Edit.
   
5. Scroll to the bottom of the page, to the Security Predicate section.
   

If your dataset has a security predicate defined, you’ll see it here.

The use-case described above—restricting user access to specific records—is very common. Here is an example of a predicate that performs this filter:

"rowLevelSecurityFilter":"'AccountOwner' == \"$User.Name\""

AccountOwner refers to the dataset field that stores the full name of the account owner for each sales target. $User.Name refers to the Name column of the User object that stores the full name of each user. CRM Analytics performs a lookup to see who’s currently logged in.

This predicate returns a match when the names in AccountOwner and $User.Name are the same. The user only sees data for which he or she is the account owner. Pretty straightforward, isn’t it? The Analytics Security Implementation Guide provides more information about security predicates and how to add them.

Well done. Now you can boast that you know all about security predicates in CRM Analytics!

What About Field-Level Security?

In Salesforce, you can implement field-level security to restrict access to individual fields on records. Even though you don’t configure field-level security in CRM Analytics, remember that CRM Analytics dataflows run using Analytics Integration User permissions. So, if you enforce field-level security on Salesforce objects, you have to assign read access to the Analytics Integration User. If you don’t, you sometimes see errors when your dataflow runs, since CRM Analytics can’t see that data.

For more details, check out the Analytics Security Implementation Guide.

Resources

• Analytics Security Implementation Guide
• Salesforce Data Access in CRM Analytics