For this week’s study guide topic we will review the Security portion of the exam. I’ve gotten feedback from others who have taken the exam that this section in particular tripped them up — make sure you know how security works inside Einstein!
- Trailhead Badges
-Analytics Administration Basics
- Salesforce Help Documentation
-Manage and Share Einstein Analytics in Apps
-Advanced Analytics Platform Setup
-Complete Setting up the Analytics Platform
- Learning Map Resources
-Analytics Security Implementation Guide
- Documentation in Exam Guide
-Salesforce Sharing Inheritance for Datasets
-Predicate Expression Syntax for Datasets
-Row-Level Security for Datasets
- Einstein Analytics Training Videos
- External Resources
-Let’s Play Salesforce: Permission Set Best Practices
-Einstein Analytics: License Assignment
-Einstein Analytics: Security Predicate for CSV file
-Security Considerations When Implementing Einstein Analytics
-Wave Security Predicates using Custom Permissions
Basic Security settings
Access to Einstein is granted through Permission Set License and Permission Set Assignments - must assign both
- Permission Set License: Grants users the ability to access Einstein, but doesn’t give them permissions to do anything inside.
— How Einstein usage is measured for your Salesforce contract
- Permission Set : A combination of the specific permission abilities inside Einstein.
— By default you get an Admin permission set and a User permission set but you can get more specific from there and add custom permission sets.
— Minimum setting for end users: Use Wave Analytics
- Trailhead uses the analogy that the PSL is your passport, but the PS is your visa.
— One grants you permission to travel but doesn’t let you in, PS gives you permission to travel inside under certain conditions.
- Salesforce creates a “Wave Integration User” when you get EA, make sure to assign Read Only access to this user to all the fields you want to utilize.
— This is the connection between your Salesforce data and the dataflow
Analytics Options within Setup
Outside of permission sets, there are other settings you can determine for users, for example:
- Show or Hide data in thumbnails
- Enable Analytics for Communities
- Enable Downloading Data from Analytics
- Enable Annotations on Widgets
- Enable Analytics REST API
Row/App Level Security
Types of security you can implement:
- None: By default, if you don’t set up a data security model, users have row level access to all data that you are displaying in Einstein
- App Access: All datasets are open but you grant access to folders
— All apps created by individuals are private by defaults; the app owner and administrators have manager access and extend visibility to other users
— Options within app are Viewer, Editor, and Manager
- Role Based: Mirror role hierarchy settings from Salesforce, i.e. “Sharing Inheritance”
— Turn on Sharing Inheritance inside Setup > Analytics and inside the Data Sync settings within data manager
— Sharing Source inside dataset editor
— Has certain limitations, must use security predicates to handle these
When you need to restrict views into external data/multi-org dashboards, etc.
- Security Predicates: filter placed on a dataset that specifies row level access
— You add these to datasets settings, and as users access datasets in Einstein the system checks to see if they have access per the predicate expression
— Can get fancy with predicates and filter based on custom user fields, profile names, etc.
— Syntax: ‘UserId’ == “$User.Id”
- No field-level security settings inside Einstein
- You can inherit sharing settings from only one object, regardless of how many objects are used to build a dataset
- Sharing Inheritance only works if a user can see 3000 rows or less in an object.
— When this happens a backup security predicate setting needs to be used
— Limitation doesn’t apply to the Opportunity object, but the Opportunity can’t have more than 150 sharing rules