Last Updated on April 25, 2023 by Rakesh Gupta

Big Idea or Enduring Question:

• How do predicate filters secure your CRM Analytics datasets based on security requirements?

Objectives:

After reading this blog, you’ll be able to:

• Use predicate filters to secure datasets
• Apply sharing inheritance to add additional security to datasets
• and much more

In the past written a few articles on CRM Analytics. Why not check them out while you are at it?!

1. CRM Analytics: Write Recipe Results to Multiple Datasets
2. CRM Analytics: Create a Dataset Using a CSV File

Business Use Case

Donna Serdula is a System administrator at Gurukul On Cloud (GoC). After reading this article, she started learning CRM analytics and created a dataset (OpportunityWithAccount_1).

Now she got a new requirement to secure the dataset rows based on the following conditions: 

1. Users should only be able to see the records they own.
2. Create a configuration that allows the administrator to grant ‘view all rows’ of the dataset to any users.

Automation Champion Approach (I-do):

Security is unique to each dataset in CRM Analytics. Users can see all rows and fields in datasets they can access by default. To restrict access to records, you can implement row-level security on a dataset when you use sharing inheritance and security predicates.

CRM Analytics provides various features to control the access to dataset rows. 

1. Integration User – By default Integration User has to view all data access. Consider removing the field access from the profile if you want to restrict access to particular objects and fields that contain sensitive data. 
2. Predicate Filters – Predicate filters run when a user accesses a dataset that is used to return only rows that match a specific condition. 
   1. Record Ownership-Based Row-Level Security – Use an Ownership-based security predicate to display only rows where the value in the Owner Id column (in the dataset) is the same logged-in user.
   2. Role Hierarchy-Based Row-Level Security – If you want to use record sharing based on Salesforce role hierarchy, create a security predicate to display rows where the logged-in user’s Role Id is in a list of parent roles above the role of the record owner. For example, to restrict access to each record in the lead dataset, you will create a security policy where users can view only leads that they own or that are owned by their subordinates based on the Salesforce role hierarchy.
   3. Territory-Based Row-Level Security – If you want to control access to dataset rows based on your defined territories, create a security predicate to display rows where users can view only data appropriate for the territory to which they belong.
   4. Team-Based Row-Level Security – Use team-based row-level security to control the access to dataset rows based on the opportunity team.
   5. Custom Row-Level Security – Applying row-level security may result in no access to data for some users. To overcome this, you can use a security predicate to give specific users access based on a value in a custom field on the User object. We will learn more about it while implementing business requirements.
3. Sharing Inheritance –
   1. Apply Sharing Inheritance to a Dataset – Sharing Inheritance allows CRM Analytics to inherit the sharing setup from a Salesforce Object and apply it to a CRM Analytics dataset without changing its contents. This feature can be applied to the following objects:
      1. Accounts
      2. Cases
      3. Contacts
      4. Leads
      5. Opportunities

To learn about predicate expression syntax for datasets, check out this help guide. 

Guided Practice (We-do):

There are 6 steps to solve Donna’s business requirement using CRM Analytics. We must:

1. First, create a custom field on the user object to grant ‘view all rows’ access to any user.
2. To sync the newly created custom field, navigate to the connection tab.
   1. Select the default local connection, i.e., SFDC_LOCAL. 
   2. Select the User object.
   3. Select the checkbox next to the CRMA Data Access field you want to sync.
   4. Click Save.
   5. In the end, make sure to Run Data Sync.
3. The next step is to update the recipe OpportunitiesWithAccount, which you created as a part of this article, to join the user object.
4. Now we have to have a value in the dataset that matches the logged-in user. For this, we will create a formula transformation used in data prep to add a derived field (View) to the dataset.
   1. For this, we will use the Transformation element.
5. Almost there! Once everything looks good, click the Save and Run button.
6. After the dataflow has been updated to include the new derived field, the security predicate can be added to the target dataset.

Formative Assessment:

I want to hear from you!

What is one thing you learned from this post? How do you envision applying this new knowledge in the real world? Feel free to share in the comments below.