Permission Set Assignment

This setting is configured in Salesforce user detail, not in Einstein Analytics. If you know how Salesforce users are assigned with extra permission using permission sets, this is exactly the same.

Depending on the Einstein Analytics licenses purchased, you will get an additional two permissions set added into your Salesforce org.: Einstein Analytics Platform Admin and Einstein Analytics Platform User for standard Einstein Analytics license or Einstein Analytics Plus Admin and Einstein Analytics Plus User for Einstein Analytics Plus. As these are prebuilt permission sets, you cannot edit the permissions, but Salesforce admin will be able to clone the permission set and adjust the system permissions.

We will not discuss each of the permissions as in Figure 8-1, but if you look at the permission name and description, some of them are pretty obvious; for “Create and Edit Analytics Dashboards” permission, without this permission, the user will be able to explore dashboards, but not create or edit any dashboards; for “Upload External Data to Analytics,” this permission gives ability for the users to load CSV file as a dataset in Einstein Analytics.

As per Salesforce permission set model, Salesforce admin can clone the permission set to many permission sets, each permission set can have different permissions enabled, and a user can be assigned with multiple permission sets.

Apps Level Sharing

The manager is the highest level of access, where users with Manager access will be able to view, edit, share, and delete the app. Users assigned with Editor access will be able to view and store dataset as a lens into the app. The Viewer users only able to view dashboard, lens, and dataset, so the user will only able to save lens or dashboard into other app where the user has editor or manager access or to store it in his/her own private apps.

However, users with Manage Analytics permissions will be able to view and edit all dashboards and lens stored in all public apps, including access to the Data Manager. While users with Einstein Analytics license and Modify All Data or View All Data permission in Salesforce will be able to see all Apps, Manage Analytics should only be given to Einstein Analytics admin users.

Security Predicate

Security predicate is a filter condition that defines row-level access for users to a dataset, so dashboards using that dataset will be applied the same row-level access. Every time users accessing dataset (including from dashboard or lens), the system will check the running users detail to compare with the security predicate defined for the dataset. You can use any field in Salesforce user object such as Profile Name, Role Id, User Id, Department, or build your own custom fields.

Security predicate is not configured in Salesforce; it will work even for dataset not imported directly from Salesforce. Security predicate just check the running users detail from Salesforce with the dataset. In some cases, we may need to add additional columns in dataset, for example, as an exception to let a profile have visibility to all data in the dataset, no matter what is the profile – in this case, the profile Id need to be added in the security predicate.

Hands-On Security Predicate

1. 1.

   Open Analytics Studio.

    
2. 2.
   Create the following dataset from CSV files; you need to change values in View_All to a valid profile Id in your Salesforce org. (see Table 8-1).

   Table 8-1

   Load the Following Table As a New Dataset and Name It “Top Account”

   Department	Account Name	View_All
   Sales	Data Inc	00eB0000000KmquIAC
   Sales	Manager Inc	00eB0000000KmquIAC
   Support	Workflow Inc	00eB0000000KmquIAC
   Sales	Process Inc	00eB0000000KmquIAC
   Support	System Inc	00eB0000000KmquIAC
   Support	Business Inc	00eB0000000KmquIAC

   **You must use Id with 18 characters, not 15 characters

    
3. 3.

   Find the dataset created, click the dataset to verify that the data loaded is correct, and you should see six records.

    
4. 4.

   Go back to the Dataset tab, and click Edit from the arrow at far right.

    
5. 5.

   Click pencil icon under Security Predicate, enter the following ‘Department’ == “$User.Department” || ‘View_All’ == “$User.ProfileId”

    
6. 6.

   When you click out of security predicate box, the system will auto check and reject if the security predicate syntax is invalid, such as “$User.Department” == ‘Department’ (wrong order), and also if the value does not exist, such as ‘Department’ == “$User.UserDepartment” (UserDepartment field does not exist in User object). However, the system will not validate and/or reject if the column name in dataset does not exist, such as ‘UserDepartment’ == “$User.Department” (UserDepartment field does not exist in the dataset).

    
7. 7.

   If the syntax check is passed, the security predicate will be saved automatically.

    
8. 8.

   Change your Salesforce user detail Department to “Sales.”

    
9. 9.
   Go back to Analytics Studio, and open Top Account dataset again; for my sample, I should only see three records as in Figure 8-2.

   

    
10. 10.

    Move the dataset to shared app from edit the dataset.

     
11. 11.

    Now log in as a user with Marketing profile, open the dataset, and it should show six records (see Figure 8-3), because we made Marketing profile Id as the exception.

     

Role Hierarchy Access

As you see from previous hands-on, security predicate supports filter on a specific Id or word; however, if we combine with “flatten” transformation to flat all Role Id in the dataflow, we can use security predicate to let users in the higher role hierarchy to access data visible for users below the role hierarchy.

Check out Figure 8-4 for a sample of the dataflow with flattening nodes.

Check out Figure 8-5 to set parameters in the flatten nodes.

You will see fields added from flatten nodes in dataflow, but not in the dataset; see Figure 8-6 for fields in dataflow.

Here is the security predicate for role hierarchy access

'OwnerId' == "$User.Id" || 'Owner.Role.Roles' == "$User.UserRoleId"

Notes

This is only to give access to specific dataset based on Salesforce role hierarchy; it is not related on the security setting for the object in Salesforce, and it also does not relate if there is sharing rules added for that object in Salesforce.

Sharing Inheritance

As you can see in the security predicate, we defined row-level security based on criteria we defined in Einstein Analytics; it has no relationship with Salesforce record security. Sharing inheritance will give us the ability to use the same row-level security defined in Salesforce; this includes object sharing, role hierarchy, manual sharing, team sharing, and sharing rules added for the object.

This sounds perfect for Salesforce customers to limit data visibility as defined in Salesforce; however, sharing inheritance has limitations; if a user can see more than 3,000 rows of data and the user does not have “View All Data” permission, sharing inheritance will not work.

Sharing inheritance is defined in the dataflow on the register node when creating dataset. Sharing inheritance is not enabled by default and is not automatically applied to the dataset.

Configure Dataflow

Let us create a new simple dataflow with two nodes as in Figure 8-7:

1. 1.

   sfdcDigest: This is to get data from an object.

    
2. 2.

   sfdcRegister: This is to store the data into a dataset.

    

To enable security inheritance, there is no difference in the dataflow sfdcDigest node; we define the object will be used as a sharing source in the sfdcRegister node. For this sample, since we only have one sfdcDigest from a Salesforce object, the sharing source is to use this object in sfdcDigest; see Figure 8-8, the sharing source is Master_Data__c object.

Result

To prove this work, let’s do a quick hands-on. For this exercise, you can use any objects with less than 3,000 records, and the object sharing setting must be set to private. Build the dataflow, and configure the sharing source as in Figure 8-7.

Figure 8-9 is a screenshot taken from a user with View All Data permission.

Figure 8-10 is a screenshot taken from the same dashboard but open by a standard user.

Summary

In this chapter, we discussed every aspect of security that can be implemented in Einstein Analytics. We start with blanket basic permissions on what a user can do in Einstein Analytics. This is defined in the permission set and can be applied per-user basis.

Next, we discussed apps security. We can share apps to users based on user name, role (including subordinates or not), and public group. As you can see, these all sharings are related to Salesforce setup. Then, similar to Salesforce report or dashboard folder, the apps manager can define the level of access for each user or role or group, from manager, editor, and viewer.

With security predicate, we can define row-level security; the system will compare user detail with data in the dataset. You can set exceptions for particular users based on role or profile or custom fields. We also can use the flatten transformation node in dataflow to give row-level access based on Salesforce role hierarchy.

The last option of security aspect that can be implemented in Einstein Analytics is sharing inheritance; this is pretty nice when you can inherit all security measure as per defined in Salesforce; however, a user is limited to have accessibility maximum to 3,000 rows only; otherwise it will not be used.

In the next chapter, which is the last chapter for this book, we will discuss advanced topics related to Einstein Analytics. We will learn a few transformation nodes in dataflow and real-time Salesforce data access with SOQL, SAQL, JSON, static step, and binding.