Free CRM-Analytics-and-Einstein-Discovery-Consultant Practice Test Questions (2026)

Explanation:

In CRM Analytics, access to dashboards is controlled at the app level.
Row-Level Security (RLS) limits what data a user can see within a dataset or dashboard.
App sharing determines which dashboards and datasets a user can even open.
Therefore:
You can use the same dataset (with RLS to restrict sales reps’ data visibility) for both dashboards.
But you must separate dashboards into different apps to restrict dashboard-level access.
This prevents sales reps from even seeing or accessing the National Performance dashboard.

Why not B:
Creating two datasets is unnecessary and introduces maintenance complexity. Both dashboards can share one dataset with proper RLS.
Why not C:
Placing both dashboards in the same app exposes the National Performance dashboard to all users with app access — even if RLS hides the data, they can still open and view its structure, which violates the requirement.

Reference:
Salesforce Help: Share CRM Analytics Apps, Dashboards, and Datasets
Salesforce Trailhead: Control Access to CRM Analytics Data (App-level vs. Row-level security)

Explanation:

The consultant’s setup exceeds the enabled object limit of 100 in CRM Analytics. While row count and storage are large enough to handle the projected volume, the bottleneck here is the total number of enabled objects, which adds up to 101. This is a configuration constraint, not a storage issue.

✅ Correct Option: A
The total number of enabled objects will exceed the limit. Adding up: 25 local objects + 10 external DB objects + (12 × 3) + (15 × 2) = 101 total objects. CRM Analytics supports up to 100 enabled objects per org. Since the total required is 101, this clearly breaks the enabled objects limit.

❌ Option B
The Salesforce external connector number of synced rows will not be exceeded. Each object ranges between 1,000 and 1 million rows, but CRM Analytics supports significantly larger row counts (up to billions depending on license). The issue is not related to rows but to the number of enabled objects.

❌ Option C
The storage rows of data limit is not exceeded either. CRM Analytics has high capacity for storage rows (billions). Even at the high end of 1 million rows per object across 101 objects, the total would be about 101 million rows, well within the data storage capabilities of a CRM Analytics Plus org.

Reference:
Salesforce Help: CRM Analytics Data Limits

Explanation:

In Salesforce CRM Analytics, when data is synced from Salesforce objects to datasets using the Data Manager, formula fields can cause discrepancies between the dataset's aggregate sum and a manual calculation from the Salesforce object. This is because formula fields in Salesforce are calculated on-the-fly and are not stored in the database as static values. When CRM Analytics syncs data, it may not capture the real-time calculated values of formula fields correctly, especially if the formula references fields that are updated asynchronously or if there are timing issues during the sync process. As a result, the dataset might reflect stale or incorrect values for formula fields, leading to differences in aggregations like sums.

Why the other options are incorrect:

Option A (Differences involving flow-updated fields):
While Flow-updated fields could potentially cause discrepancies if the Flow runs after the sync, this is less likely to be the primary cause compared to formula fields. Flows typically update stored field values, which are captured accurately during sync unless the Flow execution is misaligned with the sync schedule.
Option C (Differences involving trigger-updated fields):
Trigger-updated fields are also stored in the database and are generally captured accurately during data sync, assuming the trigger executes before the sync. Triggers are less likely to cause consistent aggregation issues compared to formula fields, which are inherently dynamic.

Key Considerations for the Issue:

Formula Field Behavior: Formula fields are not stored in the Salesforce database but are calculated when queried. If the formula depends on fields that change frequently, the synced dataset may not reflect the latest calculated values.
Sync Timing: If the sync occurs before a formula’s dependent fields are updated, the dataset will contain outdated values.

Solution Options:
Use Stored Fields: Replace formula fields with custom fields updated via a Flow, Process Builder, or Apex trigger to store static values before syncing.
Adjust Sync Logic: Use a dataflow with a computeExpression node to recalculate the formula logic in CRM Analytics after syncing.
Validate Sync: Check the sync logs in Data Manager to ensure all fields are included and no errors occurred during the sync.

Example Scenario:
Suppose the dataset includes a formula field TotalRevenue__c calculated as Quantity__c * UnitPrice__c. If UnitPrice__c is updated in Salesforce after the sync, the dataset’s TotalRevenue__c values may not match a manual sum of the updated Salesforce data.

Reference:
Salesforce Help: "Understand Data Sync in CRM Analytics"
Developer Documentation: "Formula Fields and CRM Analytics"
Trailhead: "Sync Data with CRM Analytics"

Explanation:

Correct Option: 🟢 B. Create separate datasets for attainment and commission, and apply security predicates and/or sharing inheritance.
Creating separate datasets allows precise control over access. Attainment data can be shared across the division using sharing inheritance, while commission data can be restricted to individual reps using security predicates. This ensures compliance with the requirement to limit commission visibility while allowing broader access to attainment, aligning with Salesforce’s best practices for data security in CRM Analytics.

Incorrect Option: 🔴 A. Utilize a single dataset and apply security predicates and/or sharing inheritance.
Using a single dataset complicates security management, as both fields reside together. Security predicates can filter data, but applying them to restrict commission while allowing division-wide attainment access within one dataset is complex and error-prone. Separate datasets provide clearer, more maintainable security controls, making this option less effective for the requirement.

Incorrect Option: 🔴 C. Add the sales organization to the attainment dataset access list to view commission data.
This approach fails because adding the sales organization to an access list for the attainment dataset would incorrectly grant access to commission data, violating the requirement that reps only see their own commissions. It does not leverage security predicates or sharing inheritance to enforce granular access control.

Summary: 📝
The scenario requires balancing visibility of attainment data across a division with restricted access to commission data for individual reps. Separate datasets for attainment and commission, combined with security predicates and sharing inheritance, provide a clear and secure solution. This approach ensures compliance with data access requirements while maintaining flexibility in CRM Analytics.

Reference:
Salesforce Help: Security in CRM Analytics
Salesforce Trailhead: Control Data Access with CRM Analytics

Explanation:

CRM Analytics (formerly Tableau CRM) supports custom maps using GeoJSON files to visualize geographic data. While uploading GeoJSON files is supported via the UI, this functionality is restricted by permissions.

To enable GeoJSON uploads through the UI, the user must have the “Manage Analytics Custom Maps” system permission assigned via a permission set.

Without this permission, the upload option will not be visible or accessible—even if the user has other CRM Analytics permissions.

❌ Why the other options are incorrect:
Option B: There is no separate toggle in Analytics Settings labeled “Enable Custom maps with GeoJSON.” The feature is permission-gated, not setting-gated.
Option C: Uploading via API is possible, but not required. The UI supports GeoJSON uploads if the correct permission is granted.

🔗 References:
Trailhead: Enhance Data Visualization with Custom GeoJSON Maps
Salesforce Help: CRM Analytics Permissions Overview

Explanation:

📝 The scenario involves updating a recipe to include a multi-select picklist field as text in a dashboard. Using the array_join function in the recipe converts the picklist values into a single text string, ensuring proper display in CRM Analytics dashboards while maintaining data integrity.

Correct Option: 🟢 A. Use the array_join multivalue function to convert this field to a text prior to registering the dataset.
The array_join function in CRM Analytics recipes combines multi-select picklist values into a single text string, ideal for dashboard display. This ensures the field is converted correctly before dataset registration, aligning with Salesforce’s data preparation capabilities for handling multi-select picklists in analytics.

Incorrect Option: 🔴 B. Use the array multivalue function to convert this field to a text prior to registering the dataset.
There is no array multivalue function in CRM Analytics. This option is incorrect as it references a nonexistent function, failing to address the need to convert a multi-select picklist into a text format for dashboard display. Using array_join is the correct approach.

Incorrect Option: 🔴 C. Use the string multivalue function to convert this field to a text prior to registering the dataset.
No string multivalue function exists in CRM Analytics for this purpose. This option is invalid, as it cannot convert a multi-select picklist to text. The array_join function is the appropriate tool for combining picklist values into a single text field.

Reference:
Salesforce Help: Recipe Functions in CRM Analytics
Salesforce Trailhead: Prepare Data with Recipes in CRM Analytics

Explanation:

In Salesforce CRM Analytics (Tableau CRM), App Managers have the ability to hide dashboards from specific users or user groups within the app, even if those users have Viewer, Editor, or Manager access to the app itself. This is a common permission control feature that allows fine-grained management of dashboard visibility.

Key Points:

Viewer Access:
Grants the ability to view dashboards, lenses, and datasets within the app unless they are explicitly hidden by an App Manager.
Manager Access:
Allows hiding/unhiding dashboards for specific users or groups. When a dashboard is hidden from a user, they receive a "Resource not found" error when trying to access it.

The Scenario:
End user has Viewer access to the app ✅
Project team can view the dashboard ✅
End user gets "Resource not found" ❌
This indicates the dashboard was hidden specifically from this user by someone with Manager access.

Why Not the Other Options?
A. The dashboard is deleted by a user with Manager access to the App.
❌ Incorrect: If the dashboard was deleted, the project team would also be unable to view it. The scenario confirms the project team can still access it.
C. The dashboard or App permission needs to be updated to Editor.
❌ Incorrect: Viewer access is sufficient to view dashboards. Editor access is only needed to create/edit dashboards, not view them.

Resolution Steps:
App Manager should navigate to the app
Go to App Manager → Dashboards tab
Find the affected dashboard
Check Sharing & Permissions or Hidden Users settings
Unhide the dashboard for the specific user or user group

Reference:
Salesforce Help: "Manage Dashboard Visibility in CRM Analytics Apps"
Trailhead: "CRM Analytics App Management" module
Key Concept: Dashboard-level hiding vs. App-level permissions

Explanation:

The requirement is for a chart that provides an immediate visual indicator of current performance relative to a static goal. The Gauge chart is specifically engineered for this purpose, offering a clear and direct visualization that answers the question "Are we on target?" instantly, which is crucial for sales managers monitoring key performance indicators.

✅ Correct Option: B. Gauge
A Gauge chart is the ideal choice for tracking performance against a fixed target, like a win rate goal. It visually represents the current value (e.g., 65% win rate) on a dial against predefined performance ranges (e.g., Low, Medium, High) or a specific target line. This provides sales managers with an immediate, intuitive understanding of whether they are below, meeting, or exceeding their target.

❌ Incorrect Option: A. Metric Radar
A Metric Radar chart is used to compare multiple different metrics against each other on a spider web-like grid. It is not designed for tracking a single metric, like win rate, against a specific target value. Its purpose is multivariate comparison, not univariate target measurement, making it unsuitable for this specific scenario.

❌ Incorrect Option: C. Line
A Line chart is best suited for showing trends over time (e.g., how win rate has changed month-over-month). While it could potentially include a reference line for a target, its primary function is trend analysis, not providing a clear, instantaneous snapshot of current performance against a single goal, which is the strength of a Gauge chart.

🔖 Reference:
Salesforce Help: Chart Types

Explanation:

In Einstein Discovery, understanding which variables (predictors) most influence the model’s predictions is crucial for interpreting results and building trust. This information is found in the Model Settings, where you can review:

Top Predictors: Ranked by impact on the outcome variable.
Variable Importance: Shows how strongly each predictor contributes to the model.
Excluded Fields: Lists fields that were ignored due to low predictive value or data quality issues.

Let’s break down each option:

🔹 B. Model Settings ✅
Correct. This is where you find detailed insights into:
Predictor importance
Field exclusions
Model logic and configuration
Accessible from the Einstein Discovery model manager or via the Model Evaluation tab.

🔹 A. Einstein Recommendations ❌
Refers to prescriptive suggestions (e.g., “increase discount by 5%”) based on model predictions.
Does not explain predictor importance — it focuses on actionable guidance.

🔹 C. Model Deployment Wizard ❌
Used to deploy models into Salesforce objects or flows.
Does not provide analytical insights into predictors or model logic.

🔗 Reference:
Salesforce Help: Einstein Discovery Model Settings
Trailhead: Explore Einstein Discovery Models

Explanation:

Correct Answer (B):
What is a Security Predicate? This approach utilizes a security predicate, which is the standard, scalable, and most efficient method for implementing row-level security in CRM Analytics. A security predicate is a SAQL-like filter that is applied to a dataset. It is evaluated for every query a user runs on that dataset.

How it Solves the Problem: The key is to leverage the user's attributes (like their profile or a custom field) to determine their access. The security predicate for this scenario would look something like this:
'Region' == "$User.Region" || '$User.Profile.Name' == "CXO" || '$User.Profile.Name' == "VP"

How the Predicate Works:
For a non-CXO/VP user, the second and third conditions ('$User.Profile.Name' == "CXO" || '$User.Profile.Name' == "VP") evaluate to false. The query then falls back to the first condition: 'Region' == "$User.Region". This means the user will only see records where the Region field on the data record matches the Region field on their own User record.

For a CXO or VP user, one of the last two conditions will evaluate to true. Because this is an OR condition, the entire predicate becomes true, and the filter is effectively ignored. This grants the CXO/VP user access to all records.

This solution is elegant because a single, dynamic filter on the dataset handles all user roles and permissions, making it easy to manage.

Incorrect Answers (A & C):

A. Create two sets of dashboards; one for EMEA, and one for CXOs and VPs while filtering the dashboard on the region.
Reason: This is a terrible practice. It's not a security method; it's a workaround. It's a maintenance nightmare because you have to update two separate dashboards for any change. More importantly, it is not secure. A savvy user could bypass this "filter" by simply changing the URL parameters or using a different dashboard. It does not enforce security at the data level.

C. Create two separate datasets; one for EMEA, and one for CXOs and VPs.
Reason: While this is technically possible, it is highly inefficient and difficult to maintain. You would have to duplicate all your data, dashboards, and potentially dataflows or recipes. Any change to a dataset (e.g., adding a new field) would have to be done twice. This creates data silos and makes your CRM Analytics environment difficult to manage, especially as the number of regions or access levels grows. The security predicate approach in option B is far more scalable and efficient.