Salesforce Analytics-Con-202 Salesforce Certified Tableau Next Consultant Exam Practice Test

Agent Scoping determines which approved semantic models Tableau Agent can search when a user's question lacks sufficient analytical context. Salesforce describes Agent Scoping as defining a fallback list of semantic models for a particular analytics agent. This fallback is used when Tableau Agent cannot infer the appropriate model from the current page or analytical asset.

Examples include asking Tableau Agent a question from Slack or embedding the agent on a page that contains no Tableau Next metric or dashboard. In those circumstances, the agent uses its approved fallback models to determine the appropriate semantic context.

When a user asks a question from a dashboard or metric that already supplies clear analytical context, Salesforce states that Tableau Agent uses the semantic models associated with that asset instead of the fallback list. User permissions remain enforced at runtime; placing a model on the fallback list never grants unauthorized access.

Option B is incorrect because Agent Scoping does not enforce row-level security; Data 360 governance and user permissions perform that function. Option C is unrelated to agent routing.

References/Topics: Agentic Experiences - > Tableau Agent - > Agent Scoping - > Fallback Semantic Models - > Context Resolution.

===========================================================================

For agent-specific business context about how Gross Margin % should be understood or interpreted, Business Preferences are the best choice. Salesforce uses Business Preferences to add organization-specific knowledge and instructions to a semantic model so Tableau Agent can interpret users' analytical questions according to the organization's terminology and business logic.

A calculated field is appropriate when Gross Margin % itself must be mathematically derived—for example, (Revenue - Cost) / Revenue. However, the question does not ask where to implement the mathematical calculation; it asks where to define context for AI-generated insights. Contextual instructions, such as what “healthy gross margin” means or which business interpretation to apply, belong in Business Preferences.

A dashboard-scoped calculated field is even less suitable because it confines logic to a specific downstream analytical artifact instead of enriching the governed semantic context used by Tableau Agent across conversational experiences.

Salesforce's broader semantic architecture reinforces this separation: semantic models provide standardized business logic and definitions, while Business Preferences augment those models with business-specific interpretive knowledge for conversational analytics.

References/Topics: Agentic Experiences - > Business Preferences - > Tableau Agent Context - > Semantic Model Enrichment.

===========================================================================

Data Pro—now increasingly referred to under Semantic Modeling functionality—depends on relationships already defined between the data model objects participating in a generated calculated field. Salesforce explicitly states that a predefined relationship must exist between DMOs for Data Pro to create a calculated field spanning those objects. The agent cannot construct a valid cross-object calculation when the required relationship does not exist.

Therefore, if calculations involving Sales and Customer work but introducing Territory causes the operation to fail, the most likely issue is that Territory is not relationally connected to the relevant objects.

Good metadata and field descriptions improve semantic clarity and AI accuracy, but insufficient descriptions are not the hard technical prerequisite being tested. Likewise, Salesforce does not document a general two-DMO maximum corresponding to option C.

The broader architectural principle is that generative semantic-model functionality does not replace proper data modeling. AI features consume the semantic model's existing object structure, metadata, and relationships. Consultants must establish valid relationships before expecting Tableau Agent to synthesize calculations involving fields from multiple objects.

References/Topics: Data Setup - > Semantic Models - > DMO Relationships - > AI-Generated Calculated Fields - > Data Pro/Semantic Modeling.

===========================================================================

Analytics Groups provide the native Tableau Next mechanism for sharing analytical assets with multiple users as a single administrative unit. Salesforce states that Analytics Groups are specifically designed to simplify access management by allowing an administrator to create a group, add members, and then share Tableau Next assets with the entire group rather than adding each user individually.

That makes C the direct solution for sharing a workspace with 50 users.

Custom permission sets govern functional capabilities—what users are allowed to do in Tableau Next—but are not the asset-sharing construct for granting workspace access to a collection of users. Data spaces control access to Data 360 data and governance boundaries; they are not substitutes for Tableau Next workspace sharing.

After the Analytics Group has been created and populated, the workspace owner can use the normal Share interface, select the group, and grant Viewer or Editor access as appropriate. The role applied to a workspace can then be inherited by supported assets contained in that workspace, subject to each user's underlying licenses, permission sets, and data access.

References/Topics: Managing Workspaces and Orgs - > Analytics Groups - > Workspace Sharing - > Group-Based Access Management.

===========================================================================

Semantic Data Models are specifically intended to establish standardized, reusable definitions for analytical concepts and metrics. Salesforce describes Tableau Semantics as a semantic layer that maps data to familiar business terminology and standardized logic so information can be interpreted consistently across Salesforce. Semantic models become a single source of truth for metrics, calculations, relationships, dimensions, and other analytical definitions.

Therefore, if several business units must calculate and interpret a metric consistently, the correct architecture is to define that KPI through the governed semantic model rather than recreating logic independently in each dashboard or workspace.

Workspace-level color palettes address visual presentation and branding rather than analytical definitions. Dashboard templates can standardize dashboard structure and reuse assets, but they do not provide the authoritative semantic definition layer required to guarantee that the same business metric has the same meaning everywhere.

Salesforce explicitly states that semantic models are first-class Salesforce metadata and can power analytics and data-driven experiences throughout Data 360 and Tableau Next. This reusable semantic architecture prevents divergent metric logic from developing between departments.

References/Topics: Data Setup - > Tableau Semantics - > Semantic Data Models - > Metrics - > Standardized Business Logic - > Single Source of Truth.

===========================================================================

The correct mapping is Dynamic Widget Field with a Selection interaction because the flow input must depend specifically on a value that the user selects in another dashboard widget. Salesforce distinguishes two dynamic interaction types when mapping dashboard data to Salesforce Flow inputs: Selection and Result. A Selection interaction passes the value resulting from the user's selection in a widget, whereas a Result interaction passes a value derived from the widget query results.

A Static String would supply the same manually configured value every time and therefore cannot satisfy a requirement in which the flow input changes according to what the user clicks.

Operationally, the consultant configures the Salesforce Flow action, identifies the required flow input, selects Dynamic Widget Field, chooses the source widget and field, and sets the interaction type to Selection. This creates an actionable analytical experience where a user's interaction with dashboard data can directly feed contextual values into a Salesforce business process.

References/Topics: Visualizations and Dashboards - > Analyze and Share Data - > Add Single-Click Actions to Your Data - > Salesforce Flow Actions.

===========================================================================

The most effective improvement is to ensure that time dimensions and metric semantics are clearly and correctly defined. Tableau Agent's Data Analysis capability natively supports trend analysis, period-over-period comparisons, and date filtering, including year, quarter, month, week, day, fiscal periods, and relative date ranges.

For a question such as “How has customer satisfaction trended this quarter compared to last?”, Tableau Agent must identify the correct customer-satisfaction measure or metric, understand its business definition, and resolve which date dimension establishes the comparison period. Clear metric descriptions and correct temporal metadata therefore materially improve query generation and response consistency.

Option A could create redundant semantic logic because Tableau Agent already supports period-over-period reasoning natively. A dedicated “Quarter over Quarter” calculated field is unnecessary unless there is genuinely specialized business logic that differs from the standard comparison. Option C is also inappropriate: Salesforce already provides trend and period-over-period capabilities through the Data Analysis subagent.

Well-designed semantic models—not unnecessary proliferation of specialized agents—are the primary mechanism for improving grounded conversational analytics.

References/Topics: Agentic Experiences - > Tableau Agent - > Trend Analysis - > Period-over-Period Questions - > Semantic Model AI Readiness.

===========================================================================

A Creator license is required to set proactive alerts for pipeline metrics in the scenario described. Creating an alert is more than passive consumption: the user defines a monitored condition, configures when that condition should trigger, and establishes an ongoing analytical action against the governed metric. Those capabilities fall within the Creator-level analytical configuration persona.

A Consumer can view and interact with published analytical content but does not receive the complete authoring and configuration privileges associated with creating alert definitions. The Viewer choice is even more limited and does not provide the required proactive-alert setup capability. Therefore, assigning Creator access is the appropriate licensing decision for users who must establish their own alerts.

The broader certification principle is to align licenses with the user's intended role. Users who only consume metrics should remain on the consumption tier, while users who need to create or configure analytical behavior—including proactive alert definitions—require the higher authoring entitlement. This separates governance and cost while ensuring that only appropriately licensed users can create monitoring rules.

References/Topics: Agentic Experiences - > Proactive Data Alerts - > Creator License Requirements.

===========================================================================

The semantic model should be enriched so the agent can associate the organization's business language “Earnings” with the existing Profit Margin concept. Therefore, B is the correct answer. Semantic models provide the business-context layer that allows Tableau Agent to translate natural-language terminology into governed analytical definitions. Salesforce recommends clear, contextual names and descriptions and explicitly highlights synonyms as an important semantic consideration for agent readiness.

Salesforce's Tableau Semantics training also explains that synonyms broaden the agent's understanding of terminology used by business users, allowing alternate terms to map back to authoritative metrics and definitions.

Creating a duplicate metric merely to support another phrase introduces redundant semantic definitions and increases ambiguity. Salesforce specifically recommends eliminating redundant or overlapping calculated definitions rather than multiplying them. Changing aggregation from Average to Sum would alter mathematical behavior and does nothing to resolve a terminology-discovery problem.

References/Topics: Data Setup - > Create Semantic Models - > Design Semantic Models for AI Readiness - > field descriptions, synonyms, ambiguity resolution.

===========================================================================

For a Tableau Next Metric widget to respond dynamically to dashboard filtering, two conditions must be satisfied. First, the metric widget must be configured to receive dashboard filters. Second, the dimensions being used by those dashboard filters must exist in the metric definition as supported dimensions. Salesforce specifically documents that a Metric widget can only be filtered by dimensions explicitly included in the metric definition, typically as Additional Dimensions.

Therefore, C is the only complete answer.

Option A fails because enabling dashboard-filter reception is not enough if the metric definition lacks the necessary dimensions. Tableau Next cannot apply a filter against a dimensional grain the metric does not expose. Option B has the required dimensions but explicitly disables receipt of dashboard filters, preventing the widget from responding to dashboard interactions.

This distinction is important because visualizations and metric widgets have different interaction requirements. A dashboard visualization can participate naturally in interactive filtering, whereas a governed metric must expose the appropriate dimensions in its semantic definition before those dashboard selections can alter the displayed metric result.

References/Topics: Visualizations and Dashboards - > Metric Widgets - > Receive Dashboard Filters - > Metric Additional Dimensions.

===========================================================================

The Insights tab is the appropriate feature when an analyst wants to investigate relationships and patterns quickly without first constructing a complete dashboard. It provides an exploratory surface for examining analytical behavior, discovering notable patterns, and moving from a metric or measure into deeper investigation with less authoring overhead than a full dashboard workflow.

Dashboard templates are intended to standardize and accelerate dashboard creation. They are useful when a reusable dashboard structure is required, but they still relate to dashboard authoring rather than lightweight exploration. Data Kits serve a completely different lifecycle purpose: they package and deploy supported Tableau Next and Data 360 assets between environments.

The key distinction is therefore exploration versus construction and deployment. When the business question is still being investigated, the analyst should use Insights to understand relationships first. A dashboard can be created later when the analysis needs a curated, repeatable presentation for a broader audience.

References/Topics: Visualizations and Dashboards - > Insights - > Exploratory Analysis - > Metrics and Relationships.

===========================================================================

A parameter is a user-controllable variable that can influence calculations, filtering, reference lines, and other interactive analytical behavior. Salesforce documents parameters as a mechanism for modeling scenarios and allowing dashboard users to provide inputs that affect analytical results. Parameters can be created for different data types and then referenced by calculated fields or dashboard controls.

For example, an organization could define a parameter named Target Discount and allow a user to enter 15%. A calculated field could then compare actual discount values with the parameter and dynamically change the resulting visualization. Tableau Next also supports parameter widgets that accept manually entered values or derive dynamic values from dashboard queries.

Option B incorrectly describes semantic-model relationship configuration. Relationships between DMOs are defined through relationship metadata and cardinality rather than parameters. Option C confuses parameters with governance and authorization controls.

The certification distinction is: parameters provide variable analytical input; calculated fields consume that input; semantic relationships define object connectivity; Data 360 governance controls security.

References/Topics: Data Setup - > Semantic Models - > Parameters - > Calculated Fields - > Interactive Scenario Modeling.

===========================================================================

Zero Copy Data Federation is the correct architectural approach because it allows Tableau Next and Data 360 to work with Snowflake-hosted data without creating a separate duplicated dataset. The Snowflake tables remain in the source platform while the federation layer exposes them for governed analytical use. This directly addresses both storage-cost concerns and the compliance risk associated with maintaining synchronized copies.

Option B would move the data into Salesforce custom objects through an integration flow, which creates another persisted copy and increases synchronization and governance overhead. Option C also creates replicated data through scheduled batch processing and therefore violates the stated requirement to avoid duplication. Zero-copy access keeps the source system authoritative while making the dataset available for semantic modeling and Tableau Next analysis.

The important architecture pattern is federation rather than extraction: connect Snowflake, expose the required federated data objects, apply the necessary governance, and then build the Tableau Next semantic layer over those objects. This minimizes data movement while preserving analytical accessibility.

References/Topics: Data Setup - > Data 360 - > Snowflake - > Zero Copy Data Federation - > Tableau Next.

===========================================================================

Generative AI capabilities in Tableau Semantics can directly accelerate semantic-model authoring by drafting calculated-field formulas and semantic descriptions, making A the correct choice. Salesforce supports Draft with Einstein, where the consultant describes the calculation in natural language and Einstein generates the calculated-field definition, including formula-related configuration that the author can review and save.

Salesforce also provides AI-generated semantic descriptions. These descriptions supply business context to downstream conversational analytics and help Tableau Agent correctly discover and interpret objects and fields.

Identity resolution and DMO mapping belong to Data 360 data-modeling and identity-management workflows, not the semantic-model generative-authoring capability described in this scenario. Dashboard and visualization construction is also a separate analytics-authoring process rather than the specified operation within the semantic data model configuration canvas.

The exam principle is that Tableau Agent/Semantics AI reduces semantic-authoring friction by translating natural-language analytical intent into semantic definitions, relationships, descriptions, and calculations.

References/Topics: Agentic Experiences - > generative AI for Tableau Next components; Create Semantic Models - > AI-assisted calculated fields and descriptions.

===========================================================================

Inspector Proactive Data Alerts operate against Tableau Next metrics, and Tableau Next metrics are semantic definitions created within the Tableau Semantics layer. Salesforce describes a metric as a governed business KPI derived from measures in a semantic model. Metrics can then support exploration, goals, thresholds, and Inspector alerts.

Therefore, B represents the architectural prerequisite among the supplied options. An alert must have a valid metric whose governed definition provides the measure, aggregation, temporal context, and other analytical semantics Inspector evaluates.

A user does not need to embed the metric in a dashboard. Salesforce's documented alert workflow starts from the Tableau Next metric page, where the user opens Tableau Agent and asks it to create an alert against that metric.

Option A is also not the fundamental prerequisite described by architecture. Although alert-management experiences can be reached through metric-related surfaces, the key technical dependency is the existence of the metric itself.

Current configuration also requires Tableau Agent/Data Analysis and Inspector Proactive Alerts to be enabled administratively. These are environment-level prerequisites, but they are not among the answer choices.

References/Topics: Agentic Experiences - > Inspector Proactive Data Alerts - > Metrics - > Semantic Models - > Data Analysis.

===========================================================================

A Logical View is the correct feature when the consultant needs to combine multiple data objects through an explicitly defined join and expose the resulting structure as a single reusable semantic object. Salesforce defines a logical view as a data object that combines multiple underlying objects using joins or unions rather than standard semantic relationships. The resulting logical view can then participate in relationships, calculated fields, metrics, and other semantic definitions as though it were an ordinary data object.

This distinction is fundamental. A standard relationship keeps the participating objects logically separate and describes how Tableau Semantics should traverse between them during query generation. It does not materialize their joined structure into one abstract semantic object. A Calculated Insight is used for more advanced Data 360 calculations and aggregations and does not represent the semantic-model join construct required here.

When configuring a Logical View, the consultant defines the participating objects, join criteria, join type—including an inner join when required—and appropriate cardinality. Correct join and cardinality configuration prevents duplicate or missing analytical results.

References/Topics: Data Setup - > Tableau Semantics - > Logical Views - > Joins - > Cardinality.

===========================================================================

The consultant should modify the metric definition in the underlying semantic model. Tableau Next metrics are semantic-layer objects. Salesforce defines a metric as a business KPI derived from one or more measures together with a date field, and metrics are built from semantic models.

Therefore, selecting which date dimension governs the metric's time trend is part of the metric's semantic definition rather than dashboard presentation logic. The dashboard consumes the governed metric; changing the dashboard would not correct the authoritative metric definition.

Option B is also inappropriate. Data Lake Objects and Data Model Objects define the underlying physical/logical data available in Data 360. Because the correct date field already exists in the semantic model, there is no requirement to modify the underlying DLO or DMO. The problem lies specifically in which existing semantic field the metric uses for its temporal definition.

This reflects a central Tableau Next architectural principle: reusable analytical business logic—including metrics, calculations, temporal semantics, and contextual definitions—should reside in Tableau Semantics, while dashboards remain downstream consumption and presentation layers.

References/Topics: Data Setup - > Semantic Models - > Metrics - > Measure and Date Field Configuration.

===========================================================================

The correct security mechanism is the Einstein Trust Layer's PII masking capability. Salesforce guidance for AI-assisted calculated-field creation states that the agent may use information from the semantic model, including its schema and metadata, and that personally identifiable information is masked by the Einstein Trust Layer before information is sent to the LLM.

This allows Tableau Next's generative functionality to receive the semantic context required to construct useful calculated fields while applying Salesforce's enterprise AI security controls.

Option A describes a whole-model encryption/decryption workflow that is not the documented Tableau Next processing model. Option C is also incorrect because the system does not simply prohibit every field that could potentially contain PII. Instead, the Trust Layer applies masking and other controls to protect sensitive information while retaining useful analytical context.

More broadly, Salesforce states that Tableau Agent and Agentforce inherit the Einstein Trust Layer's security, governance, and trust mechanisms, including protections designed to prevent customer data from being retained by external LLMs for model training.

References/Topics: Agentic Experiences - > Einstein Trust Layer - > PII Masking - > Generative AI Calculated Fields.

===========================================================================

Full Refresh is required when the accelerated Tableau Next cache must reflect records that were deleted in the external source. Salesforce documentation distinguishes the two acceleration modes explicitly. An Incremental Refresh adds or updates records that changed after the previous refresh, but it does not update deleted records.

By contrast, a Full Refresh removes all previously cached data during each refresh cycle and replaces it with a newly retrieved copy of the current source dataset. If a source record has been deleted, it no longer exists in the replacement dataset and consequently disappears from Tableau Next.

Incremental refresh can operate as frequently as every 15 minutes, making it attractive for high-frequency changes, but that frequency does not alter its deletion limitation. If deletion synchronization is a requirement, the architecture must account for periodic or continuous full-refresh behavior according to supported refresh intervals.

“Snapshot refresh” is not one of the documented Tableau Next Acceleration refresh methods for this use case.

This is the same architectural principle tested earlier: Incremental = added/changed data; Full = complete cache replacement, including removal of deleted source records.

References/Topics: Data Setup - > Acceleration for Data Connections - > Cache Refresh Method - > Full versus Incremental Refresh.

===========================================================================

The consultant must enable Template Builder in Tableau Next Administration. Salesforce describes Template Builder as the functionality that allows users to convert existing Tableau Next dashboards into standardized, reusable templates that can subsequently be made available through the Tableau Next Marketplace.

The administrative workflow is explicit: navigate to Tableau Next - > Administration - > Settings - > General, and enable Template Builder. Once enabled, eligible dashboard authors can use the Generate Template action to transform a dashboard into a configurable template. They can then define supporting metadata, configuration steps, descriptions, and preview information.

Tableau Next Auditing has an entirely different function: it captures user-interaction activity for governance and monitoring. It does not enable dashboard templating. “Templated Data 360 Home Org Operations” is not the documented switch for converting dashboards into Tableau Next templates.

References/Topics: Basic Setup and Admin - > Administration Settings - > Template Builder - > Tableau Next Marketplace.

===========================================================================

The limiting factor in this scenario is the user's license level. Setting proactive data alerts through Tableau Agent is an authoring-oriented capability that requires Tableau Next Creator access. A Consumer user can view and interact with published analytical content, but the Consumer persona does not receive the full set of creation and configuration capabilities needed to define alert conditions.

The fallback semantic model in option B is used when Tableau Agent lacks clear analytical context, such as when a user invokes the agent from a surface that does not already identify the relevant Tableau Next asset. Here, the user is explicitly accessing Tableau Agent from a page that contains Tableau Next content, so lack of fallback scoping is not the primary issue. Option A can prevent analysis of a particular metric, but the question establishes a broader inability to set the alert and emphasizes that the user has a Consumer license.

The appropriate remediation is therefore to use the Creator-level entitlement for users who must configure proactive alerts. This preserves the distinction between consumption permissions and analytical creation/configuration permissions.

References/Topics: Agentic Experiences - > Tableau Agent - > Proactive Data Alerts - > Creator Permissions.

===========================================================================

Option A, Draft with Einstein, can generate a calculation from natural language, but the question specifically asks about the multi-turn conversational agent experience, where the agent interacts with the user and refines the requirement. Therefore it is not the best answer. Option B addresses optimization/readiness rather than calculated-field authoring.

References/Topics: Agentic Experiences - > Tableau Agent - > Semantic Modeling/Data Pro - > Conversational Calculated Fields - > Natural-Language Authoring.

===========================================================================

The Tableau Next Sales Insights app is specifically designed to provide preconfigured sales analytics covering areas such as sales performance, pipeline health, and related operational sales measures. Salesforce describes Sales Insights as a packaged, data-driven sales solution that combines Tableau Next dashboards and analytics with Salesforce customer and sales data. It is intended to accelerate deployment rather than requiring organizations to design an analytics architecture from the ground up.

That positioning matches every constraint in the scenario: the organization already uses Agentforce Sales, has no existing analytics investment, wants minimal implementation effort, and does not intend to develop custom dashboards.

A custom Lightning Web Component would increase development, testing, governance, and maintenance effort. Full Tableau Next Creator licenses would give users broader authoring functionality than the stated requirement demands and would still leave the organization responsible for creating the analytical content itself.

Sales Insights also includes packaged semantic models, data objects, metrics, and dashboards, which substantially reduces the configuration burden compared with a greenfield Tableau Next implementation.

References/Topics: Basic Setup and Admin - > Tableau Next Sales Insights - > Packaged Analytics - > Agentforce Sales Integration.

===========================================================================

A semantic model created from a Tableau Cloud Published Data Source remains directly connected to the PDS. Salesforce states that the PDS acts as the external data definition and query source, and the integration does not create a corresponding Data 360 data object. Queries remain federated through the PDS connection.

For users configured in Tableau Cloud, Salesforce further states that record-level security and data access are inherited from the PDS. Consequently, a Tableau Next user can have access to the Tableau Next workspace, semantic model, dashboard, and visualization but still receive no usable data if their Tableau Cloud identity lacks access to the underlying Published Data Source.

Option B is incorrect because a PDS is a direct external connection and isn't represented as a DLO in Data 360. Option C is inconsistent with the scenario because the user already has the required Tableau Next asset permissions and access; moreover, the actual PDS authorization boundary remains relevant independently.

This question tests an important cross-platform rule: Tableau Next asset sharing does not override access controls enforced by the connected Tableau Cloud PDS.

References/Topics: Embedding, Cross-Cloud, and Interoperability - > Published Data Sources - > Tableau Cloud Trust - > PDS Authentication and Governance.

===========================================================================

Restricted is the correct General Access state. Salesforce documents that newly created Tableau Next assets are restricted by default. When General Access remains restricted, only individual users or Analytics Groups that have been explicitly granted access can open the asset.

For sensitive dashboards, this provides the correct baseline because access is opt-in rather than org-wide. The owner can then grant specific users or groups Viewer access and, where supported at the workspace level, Editor access.

Salesforce also makes an important distinction between Tableau Next asset access and underlying data access. Even if a dashboard is shared with a user, that action does not automatically grant permission to the DLOs, DMOs, or data spaces on which the dashboard depends. Data 360 governance still applies separately.

“Public” and “Shared” are not the documented General Access states that produce the required private-by-default behavior. Current Tableau Next access management uses Restricted as the state in which only explicitly shared users or groups can access an asset.

For sensitive content, the architecture should therefore use Restricted asset access + explicit user/group sharing + Data 360 governance.

References/Topics: Managing Workspaces and Orgs - > General Access - > Restricted - > Asset Sharing - > Data Governance.

===========================================================================