Chapter 7: Security in CRM Analytics

How do you decide who sees what in CRM Analytics? This is one of the least understood aspects of CRMA development, so in this chapter, you will learn how to secure your CRMA data. We will begin by providing an overview of CRMA security. We will then walk through each of the tools that CRMA makes available to determine who sees what data.

By the end of this chapter, you will understand the basics of CRMA security. Moving on, you will be able to deploy and manage CRMA access permissions. You will understand CRMA app-level security and be able to deploy and edit this as required. Furthermore, you will be competent in assessing and deploying Salesforce sharing inheritance. Finally, you will be confident in building and deploying security predicates.

In this chapter, we're going to cover the following main topics:

• What is CRMA security and how does it work?
• Managing CRMA access permissions
• Configuring CRMA app-level security...

Technical requirements

You will need the following to successfully execute the instructions in this chapter:

• The latest version of the Google Chrome browser (Chrome is the preferred browser when working with CRMA)
• A working email address

Ensure that you're logged into your CRMA development organization.

Let's jump right in and gain a high-level understanding of CRMA security.

What is CRMA security and how does it work?

Controlling access to information that is surfaced in CRM Analytics is critical in the broader context of data governance and security.

Important Note

Once a field is visible in CRMA, there is no way that you can prevent someone from seeing its data. Anyone who has access to the dataset has access to all fields, as opposed to Salesforce, where you have field-level security.

The CRMA administrator has four security tools at his or her disposal:

• Salesforce Data Access: The administrator can configure permissions on Salesforce fields and objects to implement field-level and object-level security, which means that access to Salesforce data can be controlled. For example, access to sensitive, personal information can be restricted at the ingestion level to prevent this data from being loaded into CRMA.
• CRMA App-Level Security: When you assign manager access to users, app owners, and administrators, they will be able to...

Managing CRMA access permissions

To ingest data and use it as a part of row-level security, you must have access to Salesforce data. Based on the permissions of the two systems of CRMA/Salesforce users, CRM Analytics gains access to Salesforce data. These two systems of CRMA/Salesforce users are as follows:

• Integration User
• Security User

Here is Integration User, as viewed in Setup in Salesforce:

Figure 7.2 – Integration User. Note the user profile; that is, Analytics Cloud Integration User

CRMA uses the permissions of Integration User when a data preparation job runs so that it can ingest data from Salesforce objects and fields. Access to any fields and objects that contain sensitive data should be restricted because the View All Data access is with Integration User.

The job will fail if the dataflow tries to read data from a field or an object where view permission is not given to Integration User.

Based on the User object...

Configuring CRMA app-level security

As you might remember from what we learned in Chapter 2, Developing Your First OOTB Analytics App in CRMA, a CRM Analytics app is similar to a folder, enabling users to organize their data projects and control the access of datasets, lenses, and dashboards, as well as how they're shared. This functionality of CRMA apps makes them a useful security tool to restrict or grant access to assets as required.

By default, all CRMA users begin with Viewer access to Shared App. An administrator may modify this setting to open or restrict access. An out-of-the-box app, My Private App, can be accessed by every user, which is suitable for personal works in progress. The contents of a user's My Private App are not visible to administrators, but lenses and dashboards can be shared with users.

Also, by default, all new apps are set to private. Manager access is with the administrators and app owner; therefore, they can extend VIEWER, EDITOR, or...

Deploying Salesforce sharing inheritance

If you want the sharing setup for your datasets to replicate the ones that are applied for your objects by Salesforce, then you can do this by deploying sharing inheritance.

Sharing inheritance reduces or eliminates the need for complex security predicates in many cases. On the flip side, applying sharing inheritance results in an increase in the time required to process data and create/update datasets – completing data syncs, recipe jobs, and more. Keep in mind that the more complicated the sharing settings are, the more impact there is on data processing time. Keep in mind that the time taken for data processing will have a higher impact if the sharing settings are more complicated.

The Salesforce admin most likely uses a combination of sharing settings to provide users with access to Salesforce data about their roles, including sharing based on the following:

• Manual sharing rules
• Role hierarchy
• Role
...

Understanding the concept and usage of security predicates

Data visibility in CRMA can be controlled using security predicates. As we mentioned earlier, row-level security for a dataset that is defined by a filter condition is called a predicate. Predicates can control data visibility based on these scenarios:

• Role Hierarchy: In the Salesforce org, predicates can filter the data based on the user's role, but only if they are logged in. A user can only view the records that are owned by them or by the people below them in the role hierarchy in Salesforce.
• Manager Hierarchy: In the User object, predicates can filter the data based on the Manager field in the User object. Therefore, the logged-in user may view the records that are owned by them, and by any user that reports under them in the manager hierarchy.
• Logged-in User's Country: The data can also be filtered based on the logged-in user's country, by the predicates. A user from one country can access...

Summary

The following diagram provides a useful summary of how security works in CRM Analytics:

Figure 7.8 – CRMA security review

As you have seen, you have a variety of options for implementing security in CRM Analytics. In this chapter, you learned about these security tools and how to deploy them.

What have you learned? First, you grasped the basics of security in CRMA. Next, you learned how to govern CRMA access permissions. Third, you learned how to use app-level security to control access to CRMA analytics app assets. Next, you became competent in configuring and enabling Salesforce sharing inheritance. Lastly, you learned how to build and deploy security predicates for more complex, detailed data governance use cases.

In the next chapter, you will learn to build your very first CRMA dashboard.

Questions

Here are some questions to test your knowledge of this chapter:

• What is the purpose of app-level security in CRMA?
• How can you control CRMA security from Salesforce objects and field access?
• When a dataflow job runs, CRMA uses the permissions of ____________ user to extract data from Salesforce objects and fields.
• What are three limitations of Salesforce sharing inheritance?
• What are three use case scenarios for security predicates?
• A security predicate expression must not exceed how many characters?
• Is this is a valid predicate expression? Why, or why not?

"Revenue">100

• A security predicate expression is case-sensitive – true or false?