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

Explanation:

When building CRM Analytics datasets that need to respect Salesforce record-level security (especially for objects like Opportunity with Private OWD and role hierarchy-based access), Sharing Inheritance is the recommended approach. However, Sharing Inheritance has limits — notably:

It supports up to 20,000 records per user.
It requires that the object be covered by Sharing Inheritance.

In this scenario, the VP of Sales may access up to 20,000 records, which is right at the threshold. Before enabling Sharing Inheritance, the consultant must verify whether the Opportunity object is eligible and whether the record access pattern fits within the limits.
🔍 Running the Sharing Inheritance Coverage Assessment allows the consultant to:
Check if the Opportunity object is supported.
Evaluate whether record access volumes per user (like the VP) are within limits.
Identify any unsupported sharing rules or configurations.

This is a critical first step before enabling Sharing Inheritance to ensure it will work as expected.

❌ Why Not A?
While enabling Sharing Inheritance and setting Opportunity as the source is the implementation step, it should only be done after confirming coverage. Jumping straight to enabling it without assessment could lead to data exposure or errors if the object isn't supported or exceeds limits.
❌ Why Not B?
Flattening the role hierarchy and using security predicates is a manual workaround when Sharing Inheritance isn’t supported. It’s complex, less secure, and harder to maintain. It should only be used if the Coverage Assessment shows that Sharing Inheritance cannot be applied.

🔗 Reference:
Salesforce Help: Sharing Inheritance in CRM Analytics
Trailhead: CRM Analytics Data Security

Explanation:

📊 Summary:
The scenario describes a development lifecycle for analytical content, where changes are made in a sandboxed environment before being promoted to production. This is a defining feature of CRM Analytics Apps, which are designed to manage and version collections of dashboards, enabling collaborative development and safe deployment without disrupting business users relying on the live version.

✅ Correct Option: A. App
The versioning feature described is a core capability of CRM Analytics Apps. Apps act as containers for dashboards and can have multiple versions (e.g., a "Live" version for all users and a "Working" version for Publishers). This allows publishers to make and test changes in isolation without affecting the live production dashboard. Once validated, the working version can be published, replacing the live version seamlessly for all users.

❌ Incorrect Option: B. Dataset
Datasets in CRM Analytics do not support this type of user-facing versioning with a "Live" and working copy. While datasets can be updated and have historical snapshots, the process is managed through dataflows and does not involve a publisher pushing a prepared version live for end-users in the same way. Dataset management is focused on data refresh, not UI/UX version control.

❌ Incorrect Option: C. Goals
This option is a distractor and does not represent a valid CRM Analytics item. "Goals" might be a concept tracked within dashboards (e.g., using a gauge chart to measure against a target), but it is not a primary asset type like an App or Dataset that possesses built-in versioning capabilities.

🔖 Reference:
Salesforce Help: Manage App Versions

Explanation:

The core of the problem is performance when previewing data from a large dataset. The "Data Preview" panel in a recipe needs to quickly show a sample of the data so the consultant can build the recipe logic. If the underlying dataset is very large, trying to preview a simple random sample can be slow.

Let's break down why C is the best solution and why the others are less effective or incorrect:

Why C is Correct:
The "Filtered Rows" sampling mode is specifically designed for this scenario. Instead of trying to randomly sample from millions of records (which can be a heavy operation), it allows the consultant to add a filter (e.g., CreatedDate = LAST_N_DAYS:30). This drastically reduces the number of records the preview needs to process, leading to a much faster and more responsive data preview. It's the most direct and efficient way to resolve the performance issue without compromising the ability to build the recipe.

Why A is Incorrect:
Reducing the sample size from the default 10,000 rows to 5,000 might offer a minor improvement, but it does not address the root cause. The bottleneck is the query to fetch any sample from a massive dataset. Cutting the sample size in half is unlikely to solve a "long time to show any results" problem and is more of a workaround than a solution.

Why B is Incorrect:
This answer is logically flawed and doesn't address the problem.
The consultant is already adding a "direct data" node, which means they are connecting to a dataset that is already registered. You cannot add a direct data node to an unregistered object.
"Register the Salesforce object" is a prerequisite that has already been met in this scenario.
The advice to "use Filtered Rows" is correct, but it is bundled with an incorrect and unnecessary first step, making the entire option invalid.

Key Concepts/References

Data Preview Sampling Modes:
In a recipe, the Data Preview panel has several sampling modes to balance performance and representation:
First Rows: The fastest, shows the first N rows ingested.
Random Rows: A true random sample, but can be slow on large datasets (this is the likely cause of the slowdown).
Filtered Rows: The best option for large datasets, as it uses a filter to reduce the data volume before sampling, significantly improving preview speed.
Recipe Performance:
When building dataflows and recipes, it's a best practice to use filtered previews to maintain a responsive development environment. The final dataflow execution will still process the entire dataset, but the preview does not need to.

In summary,
when the data preview is slow, the most effective and recommended action is to switch from "Random Rows" to the "Filtered Rows" sampling mode and apply a relevant filter to reduce the data volume being queried for the preview.

Explanation:

To allow users to view data but prevent them from exporting it, the consultant must ensure the user does NOT have the "Download CRM Analytics data" permission.
This specific system permission controls the user's ability to download the underlying data (as a CSV file) from a CRM Analytics lens or dashboard widget.
By withholding this permission, users can still access and interact with the dashboards (i.e., view the data), but the download and export options will be disabled, meeting the security requirement.

Incorrect Answers Explanation (A & C)

A. Export CRM Analytics data
While this permission sounds correct, the official and specific permission for downloading the underlying row-level data from a dashboard or lens is "Download CRM Analytics data" (Option B). "Export CRM Analytics data" is not the standard or primary permission used to govern this capability on dashboards and lenses.
C. View CRM Analytics Assets
This permission is a prerequisite for the users to be able to see the dashboards, lenses, and datasets in the first place. If the consultant were to exclude this permission, the users would not be able to view the data at all, which contradicts the requirement that they should be able to view the data.

References
Salesforce Help: Enable Downloading Data from CRM Analytics: This documentation specifies that the ability to "Download CRM Analytics Images and Export Filtered Data" is controlled by the "Download CRM Analytics data" user permission.
Salesforce Help: Learn about CRM Analytics Permission Set Licenses and User Permissions: This resource confirms that users need permissions like "View CRM Analytics Assets" to access and interact with the content.

Explanation:

When CRM Analytics (data sync/direct data) pulls currency fields from Salesforce, the platform converts them by default to the org’s default/corporate currency unless you explicitly preserve original currency values. If UC’s corporate currency is USD, synced currency fields will appear in USD on datasets/dashboards even if the source records are in GBP.

FYI:
Salesforce added a setting for Salesforce Direct Data in recipes to preserve original currency values (i.e., skip the automatic conversion to the default org currency). If you don’t use that, you get corporate-currency values.

Why the others are wrong
A. “ANS local currency is USD” — There’s no CRM Analytics setting called “ANS local currency.” Not a relevant concept/config.
B. “Integration User currency is USD” — The authoritative behavior is that data sync converts to the org’s default/corporate currency by default, not the integration user’s personal currency. (Some blogs/community posts mention the integration user, but Salesforce’s own docs state conversion is to default org currency.)

Reference
Salesforce Help (Release Notes): Preserve Original Currency Values for Salesforce Direct Data — “By default, all currency fields are converted to the default org currency on all data syncs.”
Salesforce Help: Set Your Corporate Currency — explains corporate currency for multi-currency orgs.

Explanation:

1. Error Page Indicates:
- The dashboard exists but users lost access
- Not a technical issue with the dashboard itself
- Likely a permissions change affecting visibility

2. First Diagnostic Step:
- Verify dashboard sharing settings in Analytics Studio
- Check if users still have:

• App access permissions
• Dashboard folder permissions
• Required object-level permissions

3. Why This Approach First:
- Addresses the root cause (access) rather than symptoms
- Prevents unnecessary dashboard or page modifications
- Follows security best practices

Why Not Other Options?
- Option A: Cloning would create duplicate maintenance
- Option C: Page editing won't fix permission issues

Implementation Steps:
1. Navigate to Analytics Studio > Dashboard
2. Check sharing settings for the affected dashboard
3. Verify user/group permissions in the containing folder
4. Restore access if accidentally removed

Explanation:

Correct Answer (C):

What sfdcDigest does: The sfdcDigest node is a core component in CRM Analytics dataflows and recipes. Its specific function is to extract data directly from a Salesforce object (e.g., Account, Opportunity, Case).

The Role of Data Sync: In Salesforce CRM Analytics, data sync is an essential prerequisite for most data ingestion processes. When you enable data sync for a Salesforce object, CRM Analytics creates a "staging" dataset. This staging dataset is a replica of the Salesforce object's data, which is refreshed on a schedule (the data sync schedule).

The Dependency: The sfdcDigest node in a dataflow or recipe doesn't go directly to the live Salesforce object every time it runs. Instead, it reads the data from the staging dataset that was created and populated by the data sync process. If you've just enabled data sync but haven't run it yet, that staging dataset is empty or doesn't exist.
The Failure: When the dataflow/recipe starts, the sfdcDigest node looks for its source data in the staging area. Since the sync hasn't run even once, the data is not there. This missing data source causes the node to fail, which in turn causes the entire dataflow or recipe to fail.

Incorrect Answers (A & B):

A. Dataflowsysrecipes with computeExpression nodes fail until syne has run for the first time.
Reason: The computeExpression node is a transformation node, not a data extraction node. It's used to create a new field based on a SAQL expression using data that has already been digested or loaded into the dataflow. It doesn't rely on the initial data sync. If a dataflow fails at this node, it's because of an issue with the expression itself or the data it's trying to process, not the sync.

B. Dataflows/recipes with Augment nodes fail until sync has run for the first time.
Reason: The Augment node is used to join two datasets together. It relies on the presence of two already existing datasets within the dataflow. It has no dependency on the initial data sync process. A failure at this node would be due to a join key mismatch or an issue with the datasets being joined, not the absence of the first sync run.

Explanation:

Why this is correct:
Asset Visibility lets app Managers/Editors hide specific dashboards (and other assets) within an app so that they’re not visible to Viewers. Hidden assets remain visible to users with Manager/Editor access (your sales managers) but are hidden from Viewers (your sales reps). This is exactly the use case: keep in-progress dashboards visible to managers only without duplicating content or changing app shares.

Why the others are wrong:
A. Remove from ‘Run App’ navigation list — Hiding from nav isn’t security; reps could still access direct URLs or see assets via other entry points. Asset Visibility is the supported control for per-asset visibility within an app.
B. Duplicate dashboards/datasets into a separate app — This adds maintenance overhead, risks data drift, and isn’t necessary. Asset Visibility solves the requirement without duplicating assets. (Salesforce recommends using Asset Visibility to “control who sees what in an app.”)

References:
Salesforce Help, Control Who Sees What in an App with Asset Visibility (release notes/help): describes the Hide action for assets in an app and its effect by access level.
Salesforce Help, Build CRM Analytics Dashboards: points to Asset Visibility for per-asset control in apps.

Explanation:

This question tests the understanding of how to assign CRM Analytics licenses and permissions efficiently and in accordance with Salesforce best practices.

Why C is Correct:
Permission sets are the standard and recommended way to grant granular access to features in Salesforce without modifying user profiles. In this scenario, the client has three distinct user personas:
Builders (3 users): Need CRM Analytics Data Manager and CRM Analytics Dataflow Manager permissions to build datasets and dashboards.
Dashboard Creators (15 users): Need CRM Analytics Creator permission to create dashboards but not manage datasets.
Viewers (~982 users): Need CRM Analytics Consumer permission to only view dashboards.

The consultant should recommend creating three separate permission sets, each containing the corresponding CRM Analytics permission license (Data Manager, Creator, or Consumer). These permission sets are then assigned to the respective users. This is scalable, manageable, and follows the principle of using permission sets for functional access rather than creating multiple profiles.

Why A is Incorrect:
App permissions (Viewer, Editor, Manager) control what a user can do within a specific Analytics app (e.g., view, modify, or manage the app's dashboards and datasets). However, these permissions are secondary. A user must first be assigned a CRM Analytics permission license (via a profile or permission set) to even log in to the Analytics Studio. You cannot assign app permissions to users who do not have a base license. Option A addresses the second step without solving the fundamental licensing requirement.

Why B is Incorrect:
While creating three new Salesforce profiles would technically work, it is considered a poor practice and is not scalable. Profiles are complex and control a very wide range of system permissions and settings across the entire Salesforce org. Creating multiple profiles for the sole purpose of managing CRM Analytics access is an administrative burden and can lead to unnecessary complexity in the overall user management system. Permission sets are the modern, flexible, and recommended tool for this specific purpose.

Reference
Salesforce Help: Assign CRM Analytics Permissions Licenses
This documentation outlines the process, stating: "You grant access to CRM Analytics by assigning permission sets that contain CRM Analytics permissions licenses to users." It explicitly recommends using permission sets to assign the core licenses: CRM Analytics Consumer, CRM Analytics Creator, CRM Analytics Data Manager, and CRM Analytics Dataflow Manager.

Key Concept: The process is a two-step assignment:

License Assignment: A user gets a functional license (Consumer, Creator, etc.) via a Permission Set.
App-Level Permissions: After being licensed, the user is then granted specific permissions (Viewer, Editor, Manager) within individual Analytics apps to control what they can see and do inside that app.

Explanation:

“Tablet” or “Phone” layout—where only minWidth and maxWidth have been set—may be displayed on a desktop if the dashboard is embedded in a small frame, or if the browser window is small.

Why:
CRM Analytics selects a layout based on the rendered viewport/iframe size. When a dashboard is embedded in a narrow iframe or the browser window is reduced, device-specific layouts (like Phone/Tablet) can be triggered—even on a desktop. Salesforce notes that embedded views can default to a mobile/device layout depending on dimensions, and dashboard layouts use width constraints (minWidth/maxWidth) in their JSON.

Why not A:
There isn’t a special “dashboard” vs. “phone” property parity to make mobile behave “like desktop.” In CRM Analytics you define layouts (e.g., Default/Mobile) with properties such as minWidth/maxWidth—not a “dashboard” property for desktop and a “phone” property for mobile.
Why not B:
If no mobile-eligible layout matches, the dashboard doesn’t throw a mobile error; it falls back to another layout based on size. The issue is layout selection, not an error condition on mobile while staying fine on desktop.

References:
Salesforce Help: Embedded view defaults to Mobile layout in Browser (layout chosen by embed size).
Salesforce Dev Docs: gridLayouts Properties (use of maxWidth/minWidth in layout selection/arrangement).
Salesforce Dev Docs: Dashboard JSON Overview (how layouts are defined in dashboard JSON).