A well-designed semantic model is the key to getting accurate and relevant insights with agentic analytics in Tableau Next. It helps your analytics agents understand the data and confidently answer questions. When designing your semantic model, build on a foundation of AI readiness standards and well-established industry best practices for data modeling and data quality.
Required Editions
| View supported editions. |
Semantic Model Features
To support agentic analytics across Tableau Next and Salesforce 360, a semantic model must contain Data Model Objects (DMOs) and can contain Data Lake Objects (DLOs). A semantic model can be based on a Tableau Cloud PDS.
The semantic model must contain a complete and accurate relationship map of your data. Calculated Insights (CIs) aren't currently supported.
Semantic Model AI Readiness
Building AI-ready semantic models is vital for user trust, agent performance, and business agility. By following these best practices, you not only future-proof your data models — you also accelerate your journey to scalable, agent-driven analytics.
Define clear object and field names
Agents interpret fields in the context of the objects they belong to. The clarity and specificity of object and field names and labels play a crucial role in AI interpretability.
The API names (the system name, defined at creation in Data Cloud) and labels (the display name) of objects and fields are used by AI agents.
The combination of object context and field properties drives semantic clarity. While generic labels like "ID" or "Name" may seem ambiguous in isolation, they're acceptable if the object they belong to is well-named and clearly described.
The API name can't be edited after creation in the semantic model, so it should be created thoughtfully. The label can and should be tailored for business clarity.
Unique name combinations
Ensure the combination of object name, description, and field label is sufficient for uniquely identifying the field's role and purpose. Avoid abbreviations.
Meaningful, relevant labels
Use meaningful, business-relevant display names, especially for custom fields. For example, pair an object named "Customer" with a field labeled "ID" — this is more interpretable than an ambiguous pairing like "Entity" with "ID".
Descriptive API names
When creating new fields in Data Cloud, choose API names that are as descriptive as possible to improve downstream interpretability.
Provide informative, balanced descriptions
Descriptions play a pivotal role in helping agents interpret fields and objects accurately.
Standard objects and fields
For Salesforce Standard Objects, leaving the default description may be acceptable, as these are widely known and referenced across public knowledge sources that agents are trained on. If a user modifies the description of a standard object or field, it must be additive and not contradict existing knowledge.
Use Salesforce standard objects and fields
Use Salesforce Standard Objects and Fields when designing your data model. Agents are more likely to understand and interpret standard components correctly because they are well-documented more and are used in public training data.
Custom objects and fields
For custom objects and fields, a clear and informative description is essential. It should reflect what the data represents, align with industry standards whenever possible, and explain any unique internal meanings when necessary.
Craft clear descriptions
Provide a concise, 1–2 sentence description that:
- Conveys the business context. For example, Purchase Date represents the Date field for when the invoice was printed or sent to the user. In some cases the Transaction Date and Purchase Date are different due to that reason.
- Describes how it's being used in the business. For example, Purchase Date is the default Date filter and slicer in most Purchasing and Costing related analysis.
- Represents the data well. Review the data, and make sure the description doesn’t only describe the general purpose of the field. It should elaborate if there are specific data values with a specific purpose. For example, 'NA' represents transactions in which their purchase wasn't confirmed yet and aligns with Transaction Status = 'Pending'.
Test the new description against agent understanding by asking your favorite chat tool “How do you interpret this description content for the field field name?”
Semantic models
Agents incorporate the description of a semantic model. Descriptions that include use cases and goals for the model are vital.
Describe model context
Provide a clear description of the semantic model that conveys its goals and use cases. It provides essential context about the model's purpose and scope, and improves the agent’s ability to reason about its content.
Structure the model for agent confidence
A well-connected and well-organized semantic model helps agents interpret queries correctly and answer questions accurately.
Island tables or isolated objects (tables and objects with limited or no relationships with other tables and objects) are sometimes intentionally created within a semantic model for distinct use cases. These disconnected structures can cause confusion. Both agents and users may misinterpret these structures or try to query them as if they are connected, even though relationships are not defined.
Connect model contents
Make sure all objects are part of a single connected cluster. Avoid ambiguous or unjoined objects that could trigger invalid responses from agents.
Detect and resolve ambiguities
Agents commonly analyze the full component properties when interpreting semantic models. However, it's essential to ensure that any ambiguity can be resolved solely based on the label and description level. Ambiguity can arise from the existence of similar entities or objects, similar fields, calculated fields, and metrics — and sometimes even between calculated fields and regular fields.
Agentforce for Analytics evaluates the complete set of object properties—including Object Name, Object Description, Field Display Name, Field Descriptions, Field Data Type, Field Role, Sample Values, and object/field relationships—to reduce ambiguity. However, because it's common for multiple fields to carry similar data or serve overlapping purposes, the semantic model must clearly differentiate between them through precise and intentional metadata.
Regularly run similarity and ambiguity checks
Ensure that each component created and added to the semantic model serves a unique purpose, and that this purpose is clearly captured in both the label and description.
The Semantic Model AI Optimization tool includes a Similarity scan that can address most of the scenarios described here. Use this tool in the Semantic Model Builder to quickly scan the model and reduce similarities.
Common sources of ambiguity
- Overlapping descriptions – Vague or identical field descriptions that fail to clarify distinct roles or usage. Since it's common to copy and paste descriptions, often it leads to ambiguity.
- Similar business context – Fields that represent the same concept but appear in
different tables (for example “Customer Region” from Orders Header vs. Order Line).Note
You can define business-specific knowledge in your semantic model using Business Preferences. This helps the agent respond to analytical questions within your business's unique context and logic.
- Synonyms or homonyms – Fields with different names representing the same concept (synonyms), or fields with identical names representing different concepts (homonyms).
- Objects which exist twice for different purposes and uses, but it's not clear from their
semantics that they differ. Here are some common examples:
- Same object, different purpose – A generic Date field in the model, which is being used with both Purchase Date and Transaction Date.
- Same object, different granularity – A detailed Order Lines object used for drill down to the order level when needed, and an aggregated version of Order Lines created for performance optimization.
- Constraint workarounds – An object exists more than once in the model with differing contents to get around a limitation or constraint of a source model. For example, a user extended a base model that includes an Account object with only five of the fields they need. Because they can’t adjust the base model, an additional Account object was added with all columns (existing and new). This may also be encountered in models with Published Data Sources or logical views.
Manage similar calculated fields and metrics
Agents frequently analyze formula definitions directly, which can introduce confusion even when labels and descriptions are clear. Calculated fields with similar or overlapping logic can lead to misinterpretation of the semantic model. Similarly, metrics that differ only by minor filter variations can create comparable confusion. These cases should be managed with the same rigor applied to calculated fields.
Avoid having similar calculations
Hide or remove calculated fields and metrics that don't deliver a clear, distinct analytical purpose. If removal isn't feasible, clearly define their role and differentiate them explicitly in their label and description to avoid ambiguity at the formula level.
Enrich Semantic Models with Focused Semantic Components
The semantic layer should represent business logic accurately and also anticipate how agents will consume and reason over it. Agents are aware of the relative semantic strength of different model components. Curated metrics and calculated logic carry higher intent and clarity. As a result, agents prioritize interpreting and using metrics first, followed by calculated fields, and lastly, raw fields.
Metrics as a semantic anchor
A metric is a high-value semantic object designed to answer specific business questions with clarity.
A metric includes
- Targeted calculations
- Time-scoped logic
- Contextual filtering
- Business-consistent formatting
Define metrics for important calculations
Define a metric for each high-impact and highly used calculated field or field measure. This guides agents in understanding where and when specific logic applies.
Predefined calculated fields
Calculated fields should encapsulate business logic that agents would otherwise need to infer. Defining them in advance improves answer quality, reduces ambiguity, and boosts trust.
Use calculated fields judiciously
Only include calculated fields with clear analytical purpose. Avoid overloading the model with rarely-used or overly niche calculations.
Explicit field types
Classifying fields as measures or dimensions at the metadata level enhances agent reasoning. It signals how data should behave in analytical workflows, for example, as an aggregate instead of a filter.
Assign semantic roles
Add a semantic role as field type to each field. These cues help agents apply them correctly in queries.
Validate field mappings
Validate that fields are mapped to the correct type for an optimized agentic experience. For example, for a date field, use a field type of date instead of text. This helps the agent to interpret the date field correctly.
AI-Readiness List
Use this list when building your semantic model.
Labeling and Descriptions
- Semantic Model Description is specific and purposeful.
- All field labels are specific and contextual (no “ID”, “Name” without qualifiers).
- Descriptions are provided for all custom objects and fields.
- Descriptions for standard Salesforce fields are left unchanged or enhanced without contradicting known meaning.
Ambiguity Management
- Make sure similar fields/metrics are differentiated in name, description, and purpose.
- Review calculated fields and regular fields with similar logic for overlap.
Calculated Fields & Metrics
- Only include necessary and interpretable calculated fields.
- Clarify or consolidate metrics that differ only by filters.
- Make sure each metric and field has a clearly defined analytical purpose.
Semantic Enrichment
- Define metrics are for high-impact KPIs.
- Use metrics to encapsulate time and context logic and formatting.
- Explicitly set field types (measure and dimension) for each field.
- Validate that fields are mapped to the correct type.
Model Structure
- Make sure all objects are part of a single connected cluster to avoid misinterpretation. Avoid “island tables” or disconnected data clusters.