Study guide
12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data
Salesforce Certified Data 360 Consultant formerly Data Cloud Consultant
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Solution Overview & Enterprise Value
1.1 Enterprise Customer 360 & Data Cloud Business Value 1.2 Architectural Foundation: Zero-Copy, Hyperforce, Lakehouse & Data Pipeline 1.3 Platform Terminology, Core Entities & Data Lifecycle Stages 1.4 Data 360's Foundational Role in Predictive & Generative AI
2 Chapter 2: Ethics, Privacy & Governance Fundamentals
2.1 Regulatory Compliance, Data Privacy & Ethics in Customer Data 2.2 Consent Management & Preference Enforcement in Data Cloud 2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)
3 Chapter 3: Security, Permissions & Tenant Architecture
3.1 Standard Permission Sets, User Roles & Functional Access 3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation
4 Chapter 4: Administration, Monitoring & Lifecycle Management
4.1 Data Kits & Package Automation for Cross-Org Deployment 4.2 Auditing, Status Monitoring, Error Logs & Data Explorer 4.3 Sandboxes, Change Management & Metadata Deployment
5 Chapter 5: Ingestion Connectors & Source Integration
5.1 Standard Bundles & Salesforce CRM Connectors (Sales/Service/Marketing) 5.2 Cloud Storage (S3, GCS, Azure Blob) & Streaming Ingestion (Web/Mobile SDK, Ingestion API) 5.3 Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing
6 Chapter 6: Data Lake Objects (DLO) & Data Transformations
6.1 DLO Configuration, Primary Keys, Event Time & Data Stream Categories (Profile, Engagement, Other) 6.2 Streaming & Batch Data Transforms: Formula Fields, SQL Transforms & Data Prep Recipes
7 Chapter 7: Data Model Objects (DMO) & Canonical Harmonization
7.1 Customer 360 Canonical Data Model & Subject Areas 7.2 DLO-to-DMO Mapping Patterns, Cardinality & Custom DMO Design 7.3 Data Validation, Schema Maintenance & Field Mapping Best Practices
8 Chapter 8: Identity Resolution Architecture & Match Rules
8.1 Identity Resolution Concepts, Consolidation Rate & Graph Modeling 8.2 Match Rules & Match Criteria: Exact Match vs. Fuzzy Matching (Deterministic & Probabilistic) 8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching
9 Chapter 9: Reconciliation Rules & Unified Profile Governance
9.1 Reconciliation Rules: Most Frequent, Source Priority & Last Updated 9.2 Unified Profile Schema (Individual & Contact Points) & Resolution Troubleshooting
10 Chapter 10: Segment Architecture & Audience Design
10.1 Segmentation Canvas, Segment Types (Standard UI & Flow) & Query Processing 10.2 Direct vs. Related Attributes, Cardinality & 1:N Filtering Traps 10.3 Segment Schedule, Refresh Frequencies & Exclusion Logic 10.4 Segment Membership Analysis, Population Drift & Sizing Validation
11 Chapter 11: Calculated & Streaming Insights
11.1 Calculated Insights (CI) Architecture, SQL/Builder Syntax & Dimensions vs. Metrics 11.2 Streaming Insights (SI) Architecture, Windowing (Tumbling/Sliding) & Real-Time Signals 11.3 CI vs. SI Architectural Decision Matrix & Performance Optimization
12 Chapter 12: Data Enhancements, Sharing & Analysis
12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs 12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data 12.3 Applying Predictive & Generative AI Tooling to Customer Scenarios
13 Chapter 13: Activation Targets & Outbound Activation
13.1 Activation Targets: Marketing Cloud, External Platforms, Cloud Storage & Data Spaces 13.2 Activation Configuration: Audience Mapping, Related Attributes & Payload Optimization 13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh 13.4 Activation Troubleshooting: Error Logs, Rejection Reasons & Delivery Failures
14 Chapter 14: Real-Time Data Actions & Flow Automation
14.1 Data Action Targets & Webhook/Platform Event Architecture 14.2 Data Cloud-Triggered Flows & Real-Time Business Orchestration 14.3 End-to-End Enterprise Scenario Walkthrough: Ingestion to Closed-Loop Action
12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data
Key Takeaways Explain This Topic AI
A standard Data 360 report analyses a single source: one data model object, one semantic model, or one calculated insight.
A custom Data 360 report type combines fields and records from multiple related data model objects, up to four related DMOs in one report.
Data 360 reports and dashboards run in Lightning Experience with the familiar group, filter, summarize, and chart toolset, returning near real-time results against Data 360 objects.
Reports are the governed analytical surface for business users, while the Query Editor and Query API are the exploratory SQL surface for architects; Data Explorer remains a pipeline debugging tool, not a reporting tool.
Semantic models — including models created from a data kit or from a Tableau published data source — give Tableau and Tableau Next a governed metric layer over Data 360 objects.
Last updated: September 2026
12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data
Quick Answer: Data 360 data is reportable with the ordinary Lightning Experience report builder. A standard report runs against a single source — one data model object (DMO) , one semantic model , or one calculated insight . A custom report type combines fields and records from multiple related DMOs , up to four . Reports roll up into dashboards the same way CRM reports do. For deeper analysis, semantic models expose a governed metric layer to Tableau and Tableau Next , and CRM Analytics can connect to Data 360 directly. Reporting is the governed analytical surface; the Query Editor and Query API are the exploratory one.
This section covers the "View and build reports and dashboards using Data 360" objective inside Data Enhancements, Sharing, and Analysis (18%) .
Why Reporting Matters to the Consultant Conversation
Every Data 360 implementation eventually meets the same question from the business sponsor: "We spent six months unifying this data. Where do I look at it?" If the only answers are "build a segment" or "ask an architect to run SQL," the platform looks like marketing infrastructure rather than an enterprise data asset.
Reports close that gap. They turn harmonized, identity-resolved data into something a marketing operations manager, a service director, or a finance analyst can open without a licence to a separate analytics tool and without knowing that UnifiedIndividual__dlm exists.
Standard Reports vs. Custom Report Types
Salesforce documents two report shapes for Data 360, and the distinction is directly testable:
Report Type Data 360 Source When to Use
Standard report A single DMO, semantic model, or calculated insight Analysing one source — engagement counts on an engagement DMO, aggregate spend from a calculated insight, metrics from a semantic model
Custom report type Multiple related DMOs, up to four Combining sources — unified individuals joined to orders joined to cases
The four-object ceiling on custom report types is the kind of specific limit that shows up as a distractor. If a scenario asks for a report spanning five or six related DMOs, the correct consultant answer is to pre-join upstream — a calculated insight or a data transform that flattens the relationship — and then report on the result as a single source.
Building the Report
Once the report type is in place, the workflow is standard Lightning Experience:
Group to compare meaningful categories — loyalty tier, region, acquisition channel.
Filter to focus the record set — date ranges, consent flags, segment membership.
Summarize fields to surface trends — sum, average, count, min, max.
Add a chart so the report communicates at a glance.
Run it for near real-time results against Data 360.
Dashboards
Dashboards assemble multiple Data 360 reports into a single view — one component for audience growth, one for unified profile counts by region, one for consolidation health, one for activation volumes. Standard Lightning dashboard features apply: dynamic dashboards, subscriptions, and scheduled refreshes.
Prerequisites That Trip Implementations
Reporting on Data 360 is not automatic. The recurring blockers a consultant should check before promising a dashboard:
The object has to be exposed for reporting. A DMO that has not been enabled for reporting will not appear in the report type wizard, no matter how well mapped it is.
Relationships must exist in the model. A custom report type can only traverse relationships that were actually defined between DMOs. If nobody created the relationship between the order DMO and the unified individual, there is nothing to join across.
Permissions and data spaces still apply. A user who cannot see a data space cannot report on its data. An empty report is more often a scoping problem than a data problem.
Reports read the model, not the lake. Reporting targets DMOs, semantic models, and calculated insights — not raw data lake objects. Raw DLO inspection stays in Data Explorer.
Semantic Models, Tableau and CRM Analytics
A semantic model is a governed layer of business-friendly entities and metrics defined over Data 360 objects, so that "active customer" or "net revenue" means the same thing in every downstream tool. Salesforce supports creating a semantic model from a data kit and from a Tableau published data source (PDS) , which lets an organisation that has already standardised its definitions in Tableau reuse them rather than redefine them.
Analytical Surface Fits Consultant Note
Data 360 reports & dashboards Business users who live in Salesforce Lowest friction, no extra licence, near real-time
Semantic models Shared metric definitions across tools Report on a semantic model directly, or expose it to Tableau
Tableau / Tableau Next Deep visual analysis, blended enterprise data Analyse and act on Data 360 data and insights
CRM Analytics Existing CRM Analytics investment Connects to Data 360 for dashboards inside the platform
External warehouse via data share Analysts already working in Snowflake, Databricks, BigQuery, or Redshift Covered in section 12.1 — zero-copy, external compute
Reporting vs. Query Editor vs. Data Explorer
These three get conflated constantly. Keep the personas separate:
- Tool Persona Interface Purpose
- Data 360 reports Business user Lightning report builder, clicks Governed, shareable, schedulable analysis
Query Editor / Query API Architect, data engineer ANSI SQL Exploratory analysis, validation, integration extracts
Data Explorer Architect, data engineer Object browser and filters Pipeline debugging — did the row land, is the field populated, is the mapping right
Profile Explorer Architect, service user Unified profile search Inspecting one customer's resolved 360 view
Remember the access constraint from Chapter 3: Salesforce documents that neither the Data Cloud Activation Manager nor the Data Cloud Activation Specialist permission set can open the Query Editor . That is precisely why reports matter — they are how an audience operator answers an analytical question without the SQL surface.
Worked Scenario: The Audience Health Dashboard
A retail client wants a weekly executive view covering: unified profile growth, consolidation rate trend, segment population by brand, and activation success rate.
Unified profile growth — standard report on the unified individual DMO, grouped by created date, summarized as a record count, with a line chart.
Consolidation rate trend — the raw counts are on two different objects, so pre-compute the ratio in a calculated insight and build a standard report on that insight. Trying to divide across objects in the report builder is the wrong shape.
Segment population by brand — standard report on the segment membership DMO, grouped by the brand attribute.
Activation success rate — a custom report type joining the activation-related DMOs, staying within the four-object limit.
Assemble all four as components on one dashboard , add a subscription so the executive sponsor receives it Monday mornings.
The instructive step is the second one: the moment an analytical requirement needs a ratio, a window, or a cross-object aggregation, the work belongs in a calculated insight and the report simply displays it.
Exam Traps & Consultant Pitfalls
Trap 1: Reporting on raw DLOs. Reports target DMOs, semantic models, and calculated insights. If a scenario wants to inspect what landed in a raw data lake object, that is Data Explorer, not a report.
Trap 2: Exceeding the custom report type join limit. Custom report types combine up to four related DMOs. A five-object requirement means flattening upstream with a calculated insight or data transform.
Trap 3: Reaching for Tableau by reflex. When a scenario describes a Salesforce-native business user wanting a recurring view with a chart and a subscription, the lowest-friction correct answer is a Data 360 report and dashboard — not a separate analytics platform.
Trap 4: Calling reports real-time. Data 360 reports return near real-time results. A requirement for sub-second, in-conversation data is a data graph, and a requirement for event-window detection is a streaming insight.