In this chapter we will discuss all aspects of security that can be implemented in Einstein Analytics. Same as other reporting tools, you always need to secure the access from multiple points of views, for example, to hide a particular dashboard completely from all users and only make it visible to certain users, make the dashboard visible to users, but not allow them to edit it, and so on; this is controlled in the app.
For a more advanced technique, you can show the dashboard result based on who is the user, so we can configure that everyone will not see the same results in a dashboard; this is controlled in the Dataset.
But before we look at apps and dataset security, we also can control the base permissions for the user – things that a user can do in Einstein Analytics in general, so this is a blanket permissions given for that particular user. Things like users are not allowed to download data from Einstein Analytics, or to upload external data to Einstein Analytics, and so on; this permission is controlled under the permission set.
Permission set assignment
Apps level sharing
Security predicate
Sharing inheritance
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.
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
User name
Public group
Role
Manager
Editor
Viewer
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.
Syntax
The syntax is fixed; you cannot put the dataset column after operator; it will not work.
‘ProfileId’ is API field name in dataset.
== is operator.
“$User.ProfileId” is running user profile Id in Salesforce.
You can use || as OR; && as AND; and use () to set order of operators in the security predicate.
Tips
The API field name should be within single quotes (‘ ’), while the right side of the operator should always be in double quotes (“ ”).
Region and View_All are API field names in the dataset.
We use a custom field called Region__c in the User object in Salesforce.
View_All should contain profile Id of Marketing profile for each row in the dataset.
Notes Security predicate does not support using IN or comma, so if you have multiple profiles that need to see all rows, you need to have multiple fields for each profile, for example:
'Region' == "$User.Region__c" || 'View_All_1' == "$User.ProfileId" || 'View_All_2' == "$User.ProfileId"
Hands-On Security Predicate
- 1.
Open Analytics Studio.
- 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
- 3.
Find the dataset created, click the dataset to verify that the data loaded is correct, and you should see six records.
- 4.
Go back to the Dataset tab, and click Edit from the arrow at far right.
- 5.
Click pencil icon under Security Predicate, enter the following ‘Department’ == “$User.Department” || ‘View_All’ == “$User.ProfileId”
- 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.
If the syntax check is passed, the security predicate will be saved automatically.
- 8.
Change your Salesforce user detail Department to “Sales.”
- 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.
Move the dataset to shared app from edit the dataset.
- 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.
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.
Enable Sharing Inheritance
From Salesforce setup menu, in the Quick Find box, type Analytics, and then click Settings. Look for Inherit sharing from Salesforce and select it.
Configure Dataflow
- 1.
sfdcDigest: This is to get data from an object.
- 2.
sfdcRegister: This is to store the data into a dataset.
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.
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.