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

Explanation:

Correct Answer (A):
The connection mode directly impacts how data is synced. There are two primary modes for Salesforce connectors:

Full Sync: This mode brings in all records every time the data sync runs. It's reliable but can be slow and resource-intensive, especially for large objects.

Incremental Sync: This mode only syncs new or updated records since the last sync. It's significantly faster and more efficient, making it the preferred method for large objects with frequent changes.

By evaluating the connection mode, the consultant can switch objects from Full Sync to Incremental Sync where appropriate. This is a critical step to improve performance and reduce sync time after unused fields have been removed. The consultant should also ensure the objects have a field that can be used for incremental sync, such as SystemModstamp or another date/time field.

Incorrect Answers:

B. Contact Salesforce Support to increase sync speed.
Reason: Salesforce Support does not have a "sync speed" button to toggle. Performance improvements are almost always achieved through optimization within the CRM Analytics environment, not by an external change from Salesforce. This option is not a viable solution.

C. Enable fast sync in analytics settings.
Reason: There is no "fast sync" setting in CRM Analytics. This option is a fabricated term. The actual performance optimization relies on the methods mentioned in option A, such as leveraging incremental sync.

Explanation:

🟢 Correct Answer (C):
Components: Components in CRM Analytics are reusable dashboard elements. A component can be a single widget or a group of widgets that can be created once and then added to multiple dashboards. This is the best practice for maintaining consistency and efficiency.

Maintenance: If the team needs to update the widget (e.g., change the visualization, add a new measure, or adjust the filter), they only need to edit the single component. The change will automatically be reflected on all dashboards where the component is used. This prevents the need for manual, repetitive updates.

🔴 Incorrect Answers:

A. Create/Edit a lens and add each dashboard.
Reason: A lens is a way to explore a dataset. While you can create a widget from a lens, the lens itself is not a reusable dashboard element that can be centrally maintained across multiple dashboards. If you change a lens, it won't automatically update widgets created from it on different dashboards.

B. Create/Edit the widgets individually on each dashboard.
Reason: This is the most inefficient and error-prone method. It's what the team is likely doing now. Each time a change is needed, they have to manually replicate the change on three different dashboards. This approach is not scalable and increases the risk of inconsistencies.

Explanation:

✅ Correct Answer (A):
The Purpose-Structure-Surface (PSS) framework is a recognized set of design principles, often applied in user experience (UX) and data visualization, that aligns perfectly with the discovery phase of a CRM Analytics project.

Purpose: The "Why." This phase focuses on understanding the user's goals and needs. What business questions does the dashboard need to answer? What is the user trying to achieve? This is the most critical part of the discovery session.

Structure: The "What." This phase is about determining the metrics, KPIs, and data elements required to fulfill the purpose. What data needs to be included? How should the charts and tables be organized to tell a clear story?

Surface: The "How." This is the final phase, focusing on the visual design. How should the dashboard look? What colors, fonts, and chart types should be used to make the information clear and easy to understand? This is the least important part of the discovery phase.

By following PSS, the team ensures the dashboard is meaningful and useful (Purpose) before focusing on its layout (Structure) and visual appeal (Surface).

❌ Incorrect Answers:

B. Priority - Logic - Level of Granularity
Reason: While these concepts are important in analytics, they are not the main principles of "Deep Design Thinking" in this context. "Priority" and "Level of Granularity" fall under the "Structure" principle, and "Logic" is an underlying principle of the entire build, but they are not the overarching framework.

C. Clarity - Efficiency - Consistency
Reason: These are excellent principles for the final dashboard design and user experience. They are aspects of the "Surface" and "Structure" phases but do not represent the full, user-centric discovery process. They are principles of good design rather than a framework for defining the core business problem and solution.

Explanation:

✅ Correct Option: C. Flatten the role hierarchy in the recipe and set a backup security predicate based on opportunity owner and role path.
This is the correct action because the sharing inheritance coverage assessment identified a gap for the VP of Sales. Flattening the role hierarchy within the dataflow recipe explicitly brings the user's role and all parent roles into the dataset as dimensions. A backup security predicate can then be written to grant access to records based on a user's role path, ensuring the VP's higher role in the hierarchy is recognized and appropriate access is enforced, mitigating the identified coverage gap.

❌ Incorrect Option: A. Set the organization-wide default for the Opportunity object to Public Read/Write.
This is incorrect and a severe security violation. Changing the organization-wide default (OWD) to Public would override all private sharing settings and make every Opportunity record visible to all users in the organization. This completely contradicts the core requirement that users "only see the opportunities they have access to in Salesforce," which is based on a private sharing model.

❌ Incorrect Option: B. Create a manual sharing rule to extend access to the VP of sales from the opportunity record.
This is incorrect because manual sharing rules are applied to individual records within Salesforce and are not a scalable or manageable solution for an analytics dataset. The dataflow does not ingest these granular, manually-applied sharing exceptions. The correct approach must be handled systematically within the recipe's security configuration, not via one-off record changes in Salesforce.

📊 Summary:
The consultant identified a limitation in the automated sharing inheritance process for a user high in the role hierarchy. To resolve this, they must manually enforce role-based security within the dataflow itself. By flattening the hierarchy and constructing a custom security predicate that mimics the intended Salesforce access logic, they can ensure comprehensive and accurate row-level security that covers all users, including those not fully covered by the initial assessment.

🔖 Reference:
Salesforce Help: Apply Security with Dataflow Predicates

Explanation:

Providing access to CRM Analytics is a license and permission-based process, not a profile or app-sharing one. The system administrator must assign the specific "CRM Analytics User" permission set license and the accompanying permission sets to the new manager's user record. This automatically grants them access to the platform and makes the Analytics Studio app available in their App Launcher.

✅ Correct Option: A
This is the correct method. Access to Analytics Studio is granted by assigning the pre-defined "CRM Analytics User" permission set license and corresponding permission sets (e.g., "CRM Analytics User" or "CRM Analytics Explorer") to a user. This is the standard, scalable, and recommended practice for provisioning access to the Analytics platform, making the app appear in their App Launcher.

❌ Incorrect Option: B
This is incorrect. The Analytics Studio app is not shared directly to profiles like a custom app or a record. Access is controlled exclusively through permission sets and licenses. The profile itself may contain foundational permissions (like "Api Enabled"), but the specific feature access is unlocked by the Analytics-specific permission set.

❌ Incorrect Option: C
This is an inefficient and non-standard practice. While a profile might be associated with users who have analytics access, the enabling factor is the permission set assignment, not the profile itself. Administrators should assign the necessary permission sets to the user's existing profile rather than changing their entire profile, which could affect access to other critical system features and permissions.

🔖 Reference:
Salesforce Help: Assign CRM Analytics Permission Sets to Users

Explanation:

To ensure a dashboard is truly usable on mobile devices, the consultant must actively design for it, not just assume automatic resizing will suffice. The key step is to use the Dashboard Editor's layout preview feature, specifically setting a target phone width to simulate real devices. This allows for deliberate widget arrangement, ensuring critical metrics are visible and accessible without scrolling for account managers on the go.

✅ Correct Option: A. Set the optimal Dashboard width for the Phone layout to get a more accurate preview.
This is the correct action. CRM Analytics allows a dashboard designer to explicitly set a custom width (in pixels) for the phone layout preview. This is crucial because simply relying on automatic optimization may not account for all device sizes. Manually setting a specific phone width (e.g., 375px for an iPhone) allows the consultant to precisely arrange widgets for that form factor and get a true-to-life preview during the design process.

❌ Incorrect Option: B. Make sure the dashboard automatically is optimized for mobile viewing.
This is partially true but incomplete and passive. While CRM Analytics dashboards are responsive by default, meaning they automatically adjust to screen size, this automatic process can often lead to a suboptimal user experience on small screens if the dashboard isn't actively designed for it. Relying solely on automatic optimization without proactively using the layout preview tools often results in horizontal scrolling or poorly arranged widgets on mobile devices.

❌ Incorrect Option: C. Enable mobile optimization in the analytics settings under Setup.
This is incorrect because there is no global "mobile optimization" switch to enable in Setup. Mobile functionality is inherent to the platform. The responsibility for ensuring a good mobile experience lies with the dashboard author, who must use the built-in phone and tablet layout preview modes in the Dashboard Editor to manually configure and test how widgets reflow for different screen sizes.

🔖 Reference:
Salesforce Help: Reports and Dashboards

Explanation:

Correct Option: 🟢 C. The dataset metadata locale is not overridden by individual user locale settings.
The issue arises because the dataset’s metadata is set to PST, and CRM Analytics does not automatically override this with the user’s CET locale settings. This causes the dashboard to display dates and times in PST instead of CET. Configuring the dataset to respect user locale settings ensures the dashboard reflects the correct time zone for CK users.

Incorrect Option: 🔴 A. The developer turned off dynamic time zone in CRM Analytics settings.
Dynamic time zone settings are not a standard feature in CRM Analytics that directly controls dataset locale behavior. The issue stems from the dataset’s metadata locale (PST) not aligning with the user’s CET locale, not from a specific dynamic time zone toggle being disabled, making this option incorrect.

Incorrect Option: 🔴 B. Data within datasets is modified for localization or internationalization.
Dataset data is not modified for localization or internationalization in CRM Analytics. The issue is related to the dataset’s metadata locale (PST) not being overridden by the user’s CET locale, causing the dashboard to display incorrect times. This option misattributes the problem to data modification, which is not relevant.

Summary: 📝
The scenario involves a dashboard displaying incorrect date and time due to a mismatch between the dataset’s PST locale and CK’s CET locale. The dataset’s metadata locale is not overridden by user settings, causing the discrepancy. Adjusting the dataset to respect user locale settings resolves the issue, ensuring accurate display.

Reference:
Salesforce Help: Time Zone Considerations in CRM Analytics
Salesforce Trailhead: Manage Data in CRM Analytics

Explanation:

Correct Option: 🟢 C. Custom transformation with a multiple row formula to calculate the duration.
A custom transformation with a multiple row formula in a recipe allows the consultant to calculate the time difference between stage transitions in the Opportunity History object. By referencing multiple rows (e.g., start and end dates), the formula computes the duration per stage, enabling accurate aggregation for average time calculations in CRM Analytics.

Incorrect Option: 🔴 A. An aggregate transformation with offset parameter to calculate the duration.
Aggregate transformations in CRM Analytics summarize data (e.g., sum, average) but cannot calculate durations across multiple rows, such as time between stage transitions. The offset parameter is not designed for this purpose, making this option unsuitable for computing the time an opportunity spends in each stage.

Incorrect Option: 🔴 B. Flatten transformation with offset expressions to calculate the duration.
Flatten transformations restructure hierarchical data but are not suited for calculating time durations across rows. Offset expressions are not a feature in flatten transformations for this purpose. A custom transformation with a multiple row formula is needed to compute stage durations accurately, making this option incorrect.

Summary: 📝
CK needs to calculate the average time opportunities spend in each stage using Opportunity History data. A custom transformation with a multiple row formula in a recipe enables precise duration calculations by comparing stage transition timestamps. This approach supports aggregating durations to derive averages, aligning with CRM Analytics capabilities.

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

Explanation:

✔️ When records exceed 400 sharing descriptors, the only sustainable way to enforce row-level security is through security predicates. This allows filtering based on user context without relying on sharing inheritance limits. Both requesting Salesforce Support or attempting to adjust analytics settings won’t resolve the issue.

✅ Correct Option: A
Using security predicates in CRM Analytics is the correct solution. Sharing inheritance works best with records that stay within the 400-sharing-descriptor limit. When this limit is exceeded, applying security predicates at the dataset level allows filtering data by user attributes, bypassing the descriptor limit while still enforcing row-level security. This ensures performance and compliance without hitting sharing inheritance constraints.

❌ Option B
Contacting Salesforce Support to increase the sharing descriptor limit is not viable. The 400-descriptor cap is a hard system limit and cannot be raised by Salesforce Support. Attempting this route will only waste time, as Salesforce enforces this limit for system performance and reliability reasons.

❌ Option C
There is no way to increase the sharing descriptor limit through CRM Analytics settings. Limits like 400 descriptors are baked into Salesforce architecture. Analytics settings allow for adjustments in areas like row-level security or data sync, but they cannot override structural platform restrictions.

Reference:
Salesforce Help: Sharing Inheritance Limits and Security Predicates

Explanation:

✅ Correct Option: B
The dataset explorer allows modification of both field labels and default fields. Designers can rename API labels into user-friendly names directly within the dataset, and the default fields (and their order) that appear in a values table are defined at this level. This ensures consistent labeling and ordering across dashboards without manual edits in every widget.

❌ Option A
Changing field order in the JSON of a value table widget is not the recommended or sustainable approach. While JSON editing allows some customization, it only applies to a single dashboard widget and doesn’t fix the root cause: how default fields are set at the dataset level. This creates inconsistency when using fields in new widgets.

❌ Option C
Field labels cannot be changed only in widget properties. Editing labels in widget properties affects presentation for that widget alone but does not address the broader issue of API labels appearing across the dataset. Without modifying the dataset explorer, labels will continue to display in API form elsewhere.

Summary:
To resolve both the API label display and random field order issues, the consultant should point the designer to the dataset explorer, where field labels and defaults are set. This provides consistent naming and ordering across all dashboards, rather than relying on per-widget or JSON-level fixes.

Reference:
Salesforce Help: Dataset Explorer in CRM Analytics