Analytics-Con-201 Salesforce Certified CRM Analytics and Einstein Discovery Consultant Exam Topics and Questions

This topic sets the foundation for everything that follows. You need to know how to provision CRM Analytics correctly, control who can use it, and move work between environments without breaking it. The weight is moderate, but the scope is broad: licensing models, permission structures, API capabilities, and deployment mechanics all appear. Weak knowledge of any one piece will cost you marks.

– Licensing, permissions and feature enablement

Enabling CRM Analytics means more than flipping a switch. You assign permission sets and licenses to the right users, and you need to know which combinations unlock which features. Different licence types carry different entitlements, and the exam expects you to match business requirements to the correct permission model. You also enable specific features within CRM Analytics itself, such as embedded dashboards or Einstein Discovery integration. The question is always: given these users and this requirement, what permissions and licences do you assign? Miss the dependency between a feature and its required permission set, and your solution fails.

– Limits, API use and deployment

Data sync, dataflow and recipe execution all run inside governor limits. The exam gives you a scenario with volume or complexity constraints and asks you to design within them. You need to know where the ceiling is and how to stay under it. The CRM Analytics API appears less frequently, but when it does, the question tests whether you understand what can be automated or extended programmatically versus what must be done in the UI. Deployment questions focus on moving assets between sandboxes and production. You need to recognise which migration path fits the requirement: change sets, metadata API, or manual rebuild. The trap is assuming one method works for all scenarios.

How Admin/Configuration is tested

Seventeen percent means roughly one in six items. Questions present a business requirement and ask you to configure the platform to meet it. You are given a user role, a feature need, or a deployment constraint, and you choose the correct combination of licence, permission set, API action or migration strategy. The most common mistake is conflating permissions with licences, or assuming a feature is available when the required permission set has not been assigned. Deployment questions trip candidates who do not recognise that certain assets cannot move via change sets. API questions fail when you overestimate what the API can do or assume a manual task can be scripted. Read the requirement carefully and match it to the exact enablement step, not the general concept.

Data Layer carries the highest weight on the exam. Nearly a quarter of your marks come from knowing how to extract, transform, refresh and manage datasets. This is where most candidates either prove their hands-on experience or reveal they have only read about the platform. The topic spans Data Manager, dataflows, recipes, refresh schedules, transformations and extended metadata. Every sub-area is examinable, and the questions assume you have built datasets under real constraints.

– Extraction, loading and dataset creation

You use Data Manager to connect to data sources and create datasets. The exam expects you to know which connectors are available, how to map fields during extraction, and what happens when source schema changes. Questions present a scenario with multiple data sources and ask you to choose the correct extraction method. The trap is assuming all sources behave the same way. Salesforce objects, external databases and CSV uploads each have different behaviours and limitations. You need to recognise which approach fits the source type and the business need.

– Refresh schedules, limits and transformations

Once data is in, you keep it current by scheduling dataflows and recipes. The exam tests whether you understand refresh frequency limits, how to sequence dependent flows, and what happens when a refresh fails. Transformation questions give you a business requirement and ask you to implement it using dataflow nodes or recipe steps. You need to know which node type handles which operation: augment, filter, compute, flatten, join. The mistake is choosing a node that looks right but does not perform the exact transformation required. Limits reappear here. You are given a scenario with high row counts or complex transformations and asked to design within governor constraints.

– Extended metadata and delivery management

Extended metadata controls how fields appear in lenses and dashboards: labels, formatting, default colours. The exam asks you to edit XMD to meet user requirements, such as changing a date format or reordering dimension values. Delivery management covers versioning and conversion. You need to know when to version a dataflow or recipe, how to roll back, and what happens when you convert a dataflow to a recipe. Questions present a change-control scenario and ask you to choose the correct versioning or conversion strategy. The trap is assuming conversion is always safe or that versioning is automatic.

How Data Layer is tested

Twenty-three percent means this topic appears more than any other. Questions give you a data source, a business need, and a set of constraints, then ask you to design the extraction, transformation and refresh strategy. You are tested on node selection, limit awareness, refresh sequencing, XMD editing and versioning. The most common failure is choosing a transformation step that works in theory but exceeds a limit or does not handle nulls correctly. Another trap is assuming a dataflow and a recipe are interchangeable when they are not. The exam also tests whether you know what happens when source data changes: does the dataset update automatically, or do you need to edit the flow? Read the scenario for volume, source type and refresh frequency, and choose the solution that fits all three.

Security determines who sees what, and the exam expects you to implement both user-level and row-level controls. You work with permission sets, sharing inheritance, security predicates and app-level sharing. The weight is moderate, but the consequences of a wrong answer are high: if you misconfigure security, the solution fails compliance. Candidates who have not implemented predicates in a production org will struggle here.

– User, group and profile security settings

Governance starts with controlling access to CRM Analytics assets. You assign permissions to users, groups and profiles, and you need to know which setting controls which capability. The exam gives you a governance requirement and asks you to configure the correct permission model. The trap is assuming Salesforce profile permissions automatically extend into CRM Analytics. They do not. You need to assign CRM Analytics-specific permissions separately. Questions also test whether you understand the difference between app access, dataset access and dashboard access, and how they interact.

– Row-level security: sharing inheritance and predicates

Row-level security controls which records a user sees within a dataset. Sharing inheritance applies Salesforce object sharing rules to the dataset, so users see only the rows they can access in the source object. Security predicates apply a filter at query time based on user attributes. The exam tests whether you know when to use inheritance, when to use predicates, and when to combine both. The mistake is choosing inheritance when the requirement calls for a custom filter, or writing a predicate that does not reference the correct user field. You also need to know what happens when inheritance and predicates conflict, and which takes precedence.

– App sharing

App sharing determines who can open an app and what they can do inside it. You assign access to individual users or groups, and you set permissions for viewing, editing or managing. The exam asks you to configure app sharing to meet a user requirement, such as giving a sales team view access but restricting edit rights to admins. The trap is assuming dataset security automatically flows through to app security. It does not. You configure them separately, and both must align for the user to see the correct data.

How Security is tested

Sixteen percent means roughly one in six or seven items. Questions present a governance or row-level requirement and ask you to implement the correct security control. You are tested on permission assignment, sharing inheritance, predicate syntax and app-level access. The most common mistake is choosing sharing inheritance when a predicate is required, or writing a predicate that references the wrong field. Another trap is assuming security settings cascade automatically when they do not. The exam also tests your understanding of what happens when multiple security controls apply to the same dataset: which rule wins, and what does the user see? Read the requirement for the user role, the data scope and the compliance constraint, then choose the control that enforces all three.

Design comes before implementation. This topic tests whether you can scope, validate and prioritise dashboard requirements, then translate them into a design that follows best practice. You also need to recognise when a standard templated app meets the need and when custom development is required. The weight is lower than Data Layer or Security, but weak design produces dashboards that answer the wrong question, no matter how well they are built.

How Analytics Dashboard Design is tested

Thirteen percent means this topic appears less frequently than Data Layer or Security, but the items demand judgement rather than recall. You are given a business requirement and asked to scope it, validate it against user needs, or prioritise it within a backlog. Design questions test whether you know CRM Analytics UX principles: which chart type suits which data shape, when to use a compare table versus a timeline, how to structure filters so users can explore without confusion. Templated app questions ask whether a standard app meets the requirement or whether customisation is needed. The trap is choosing a template because it looks close when it does not meet the core need. Another mistake is prioritising features that look impressive over features that answer the business question. Read the requirement for the user role, the decision they need to make, and the data they need to make it, then design to that.

Implementation turns design into working dashboards. This is the second-highest weighted topic, and it assumes you have built dashboards in production. You configure widgets, bind queries, create interactions, apply advanced functions like windowing and time series, embed dashboards in Lightning pages, and optimise performance using Dashboard Inspector. You also manage versions and use Dashboard Publisher. Every sub-area is hands-on, and the exam expects you to know which configuration achieves which result.

– Widget configuration and query binding

Widgets display data, and each widget type has parameters that control what it shows and how it behaves. The exam gives you a business requirement and asks you to configure the correct query type and widget parameters. You need to know the difference between a SAQL query, a compare query and a values table query, and when to use each. Widget-level parameters include groupings, measures, sorting, limits and conditional formatting. The trap is choosing a parameter that looks right but does not produce the exact output required. Another mistake is assuming all widgets support all query types when they do not.

– Interactions and advanced functions

Selection and result interactions let users click one widget and filter another. The exam tests whether you can configure bindings so interactions behave as expected. You need to know how to pass selections between widgets, how to reset filters, and what happens when multiple interactions conflict. Advanced functions include windowing, which calculates running totals or moving averages, and time series analysis, which compares periods or trends over time. Questions present a requirement like "show year-over-year growth" or "display a rolling three-month average" and ask you to configure the correct function within a compare table. The mistake is choosing a function that looks close but does not handle the date grain or grouping correctly.

– Embedding, performance and delivery management

Embedding dashboards in Lightning pages makes them actionable within the Salesforce UI. The exam tests whether you know how to configure the component, pass context, and control access. Dashboard Inspector helps you monitor query performance and identify slow widgets. You need to know how to interpret the Inspector output and what optimisations to apply: reducing query complexity, limiting rows, or adjusting groupings. Delivery management covers versioning and Dashboard Publisher. Versioning lets you roll back changes; Publisher lets you deploy dashboards to multiple apps. Questions ask you to choose the correct strategy for a change-control or distribution requirement.

How Analytics Dashboard Implementation is tested

Nineteen percent means this topic appears almost as often as Data Layer. Questions give you a business requirement and ask you to configure the widget, query, interaction or advanced function that meets it. You are tested on query type selection, parameter configuration, interaction binding, windowing, time series, embedding, performance tuning and versioning. The most common mistake is choosing a configuration that works in a simple case but fails when filters or groupings are applied. Another trap is assuming Dashboard Inspector recommendations are always correct when sometimes they conflict with business requirements. The exam also tests whether you know what happens when you version a dashboard or publish it to multiple apps: does the change propagate, or do you need to republish? Read the requirement for the user action, the data response and the performance constraint, then configure to meet all three.

Einstein Discovery builds predictive models from your data and surfaces insights. This topic tests whether you can select the right prediction type, assess model quality, improve results by adjusting data, enable predictions in Salesforce and CRM Analytics, and interpret model performance using the Model Card. The weight is the lowest on the exam, but the questions assume you have trained a model and iterated on it. Theory alone will not carry you.

– Model building and prediction types

You start by assessing your data and choosing one of three prediction types: numeric, binary classification or multi-classification. The exam gives you a business outcome and asks you to select the correct type. Numeric predictions forecast a continuous value, such as revenue or days to close. Binary classification predicts yes or no, such as win or loss. Multi-classification predicts one of several categories, such as product tier. The trap is choosing binary when the requirement calls for multi-class, or assuming you can switch types after training without rebuilding the model. You also need to know what data quality issues prevent a model from training: missing values, low cardinality, insufficient rows.

– Model analysis, iteration and improvement

Once the model is built, you analyse the results and propose improvements. The exam tests whether you understand model metrics: R-squared for numeric predictions, precision and recall for classification. You interpret insights to identify which variables drive the prediction and whether the model is overfitting. Iteration means adjusting data parameters, adding or removing columns, or filtering rows to improve accuracy. Questions present a model result and ask you to recommend the next step: add more data, remove a low-signal column, or re-bin a categorical field. The mistake is assuming more data always helps when sometimes the issue is data quality, not quantity.

– Deployment and monitoring

You enable predictions on Lightning record pages and in CRM Analytics dashboards, so users see recommendations in context. The exam tests whether you know how to configure the component, map prediction fields, and control access. The Model Card displays model performance over time: accuracy, drift, bias. You need to know how to interpret the card and when to retrain. Questions ask you to identify when a model is degrading and what action to take: retrain with fresh data, adjust the training window, or investigate bias in a protected attribute.

How Einstein Discovery is tested

Twelve percent means this is the lightest topic, but the items are specific. You are given a business outcome, a dataset or a model result, and you choose the correct prediction type, improvement action, deployment configuration or monitoring response. The most common mistake is selecting the wrong prediction type because you did not read the outcome carefully. Another trap is assuming model accuracy is the only metric that matters when precision, recall and bias all affect production performance. Deployment questions fail when you do not know how to map prediction fields to record pages or when you assume predictions are automatically available to all users without configuration. Read the scenario for the business goal, the data characteristics and the deployment context, then choose the option that fits all three.