Reporting on Data 360 with native Salesforce reports: the DMO report types, the join you can't make, and the access nobody enabled

You spent a quarter unifying six source systems into Data 360, resolving identities, and building a clean set of Data Model Objects. Then someone in operations asks the question that quietly deflates the whole project: “Great — can I just get a report on it?” Not a segment. Not an activation. Not a dashboard an agent grounds on. A plain Salesforce report, in the report builder they’ve used for years, that they can filter, group, export, and drop on a dashboard. For a long time the honest answer was “not really — query it with the Query API or SOQL, or push it somewhere else and report there.” That answer is no longer correct, and a lot of teams don’t know it changed.

Native Reports & Dashboards on Data 360 let analysts and admins report on Data Cloud data with the same point-and-click builder they use for standard objects. No SQL, no separate BI tool, no export. It’s one of the most quietly useful features in the platform — and also one of the most misunderstood, because it comes with an enablement step everyone skips, a join limitation that will surprise you the first time you hit it, and a real question about when a native report is the right tool at all. This is the practitioner’s map.

Data Cloud became Data 360 in Salesforce’s October 2025 rebrand. The reporting feature is the same one that shipped as “Data Cloud Reports and Dashboards”; the product name moved, the mechanics didn’t.

The mechanism: report types are generated, not built

Here’s the part that makes this feel like magic the first time. In standard Salesforce, custom reporting on a custom object means an admin hand-builds a custom report type — pick the primary object, add related objects, expose fields. In Data 360, report types are generated automatically for every mapped Data Model Object. Map a DLO to a DMO, and a corresponding report type appears, ready to use.

You find them through a dedicated “Data Cloud” report category on the New Report screen. Pick that category, choose the report type for the DMO you care about — say, Unified Individual, or your Order or Subscription DMO — and you’re in the standard report builder, grouping and filtering DMO fields exactly as you would Account fields. The report runs against the DMO’s data through Data 360’s own query engine, so what you’re reporting on is the unified, resolved record — not the raw source rows sitting in a Data Lake Object.

That distinction is the whole value and it traces straight back to the modeling discipline. A report is only as good as the DMO underneath it, which is why the DLO-to-DMO mapping is the step that decides everything downstream. If the mapping over-collapses two customers into one profile, your report cheerfully counts them as one. The reporting layer inherits every modeling decision you made; it doesn’t rescue a sloppy one.

The join you can’t make yet, and how to design around it

Now the limitation that will bite you, stated plainly so you design for it up front: you can join DMOs together in a Data 360 report type, but you cannot join a Calculated Insight with other Calculated Insights or with DMOs.

Read that carefully, because the nuance matters. You can report on a single Calculated Insight — there’s a report type for it, and grouping a CI’s dimensions and measures in a Lightning report works. What you can’t do is build one report that joins a CI to a DMO — for example, “show me each unified individual’s lifetime-value CI next to their support-case DMO records in a single report.” Those live in separate report types today. Salesforce has signaled CI joins are on the roadmap, but “on the roadmap” is not “in your org,” so build as if the wall is there.

The design implications are concrete:

• Model the fields you’ll report on into the DMO, not only into a CI. If a metric needs to appear alongside profile or transactional attributes in one report, it has to be a DMO field, not stranded in a Calculated Insight. That sometimes means materializing a derived value back onto a DMO rather than leaving it purely as a CI — a modeling choice you want to make deliberately, weighing it against the credit cost of calculated versus streaming insights.
• Use the right tool for cross-CI analysis. When you genuinely need to correlate multiple insights, that’s the job of a Calculated Insight that already joins the inputs, or of Tableau Next and its semantic model — not of a native report you’re trying to force a join into.
• Keep report types single-DMO where you can. Multi-DMO joins work, but each join is a query the engine has to resolve at run time, and wide joins over large DMOs are where reports get slow and credit-hungry. Report narrow; reach for a pre-joined DMO or CI when the report itself is doing too much work.

The enablement step nobody did

The single most common reason a team concludes “Data 360 reporting doesn’t work in our org” is that it was never turned on, and the failure is silent — the “Data Cloud” report category simply doesn’t appear, with no error explaining why. Two things have to be true.

First, the org and the user need Data 360 access. The user must have access to Data 360 — through a Customer Data Platform or Data 360 license — with the corresponding permission enabled in a permission set. In older orgs this reads as “Allow user to access the Genie Platform / Data Cloud”; the wording has followed the rebrand, but the effect is the same: no Data 360 permission, no Data 360 reports. This is the same permission-set discipline that governs what an agent is allowed to see in Data 360 — reporting access is a grant, not a default.

<!-- The Data 360 access that must be present in the user's permission set -->
<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
    <label>Data 360 Analyst</label>
    <userPermissions>
        <enabled>true</enabled>
        <name>CustomerDataPlatformAdmin</name>
    </userPermissions>
    <!-- plus object/field access on the DMOs to be reported on -->
</PermissionSet>

Treat that snippet as the idea, not a copy-paste — the exact permission API name depends on your edition and license, and you should confirm it against the permission your Data 360 license actually provisions rather than assuming a name.

Second, there has to be something to report on. The Data 360 report option only surfaces when you have an active DMO mapped to a DLO. A DMO with no data flowing into it, or a DLO you never mapped, produces no report type. The check when the category is missing is therefore mechanical: confirm the Data 360 permission on the running user, confirm reporting is enabled for the org (Setup → Reports and Dashboards Settings), and confirm at least one DMO is genuinely mapped and populated. Nine times out of ten it’s one of those three.

What actually runs when the report runs

A native report on a DMO is not free the way a report on an Account is. Standard-object reports run against your Salesforce database; Data 360 reports run against Data 360’s storage through its query engine, and that engine is metered. Every report execution is a query, and queries against Data 360 draw on consumption the same way the Query API and SOQL access do. A dashboard of ten Data 360 components on auto-refresh, opened by fifty people a day, is fifty times ten queries a day against a metered engine — a very different cost profile from the “reports are basically free” instinct everyone brings from core CRM.

The practical guidance follows from that:

• Snapshot the expensive stuff. For a metric that’s read constantly but changes slowly, consider computing it on a schedule (a Calculated Insight, or a Data Cloud pipeline) and reporting on the result, rather than re-querying raw DMOs on every dashboard load.
• Filter early and hard. A report scoped to a date window and a segment reads far less than an unbounded report over a multi-billion-row DMO. The filter is a cost control, not just a convenience.
• Watch dashboard refresh. Scheduled and on-open refreshes multiply query volume quietly. Set them to what the business actually needs, not to “as often as possible.”

None of this makes native reporting a bad choice — it makes it a choice with a meter, which is true of everything in Data 360 and worth internalizing before someone builds an executive dashboard that reruns the whole customer base every fifteen minutes.

When a native report is the right tool — and when it isn’t

Native Data 360 reporting is the right answer in a specific shape of situation: an admin or analyst who lives in Salesforce reports, needs to slice unified DMO data with familiar grouping and filtering, wants it on a Lightning dashboard next to their CRM reports, and doesn’t need to join across insights or crunch billions of rows interactively. That covers a lot of real “just give me a report on the unified data” requests, and delivering it in the tool people already know — with no new license and no export pipeline — is a genuine win.

It’s the wrong tool when the job is bigger than a report:

• Cross-insight, large-scale, or visually rich analytics belong in Tableau Next, where the semantic model and a purpose-built engine handle joins and scale the report builder isn’t designed for.
• Programmatic access — feeding a downstream system, an external app, or a notebook — belongs on the Query API, not on a Lightning report you’d have to scrape.
• Grounding an agent on your data is not a reporting task at all; that’s retrievers and the semantic layer, a different pipeline with different guarantees.

Choosing the native report when it fits, and refusing it when the job is really a BI or integration or grounding problem, is the whole skill. The feature’s value is that it closes the “I just want a report” gap without a second platform — as long as you don’t stretch it into the jobs those other platforms exist to do.

The takeaway

Data 360 can be reported on with the native Salesforce report builder, no SQL and no export required: report types are generated automatically for every mapped DMO, surfaced under a “Data Cloud” report category, and run against your unified records through the metered Data 360 query engine. Before you build, get three things right — enable the Data 360 access permission on the running user, make sure at least one DMO is mapped and populated so the report type appears, and design around the fact that you can report on a single Calculated Insight but can’t yet join a CI to a DMO. Filter hard and snapshot slow-moving metrics to keep the query meter honest, and reach past native reporting to Tableau Next, the Query API, or the grounding pipeline when the job outgrows a report. Get that right and the last mile of a Data 360 program — actually letting people see the unified data — stops being an afterthought and becomes a click.

Understanding the basics

Can you build native Salesforce reports on Data 360 data?

Yes. Data 360 (formerly Data Cloud) supports native Reports & Dashboards: when you map a Data Lake Object to a Data Model Object, Salesforce automatically generates a report type for that DMO, available under a “Data Cloud” report category on the New Report screen. You then use the standard Lightning report builder — grouping, filtering, charting, and dropping the report on a dashboard — against your unified DMO data. No SQL and no export to an external tool is required, though the report runs against Data 360’s metered query engine rather than the core CRM database.

Why don’t I see the “Data Cloud” report category?

Almost always one of three things is missing. The running user needs Data 360 access — a Customer Data Platform or Data 360 license with the matching permission enabled in a permission set. The org needs Data 360 reporting enabled (Setup → Reports and Dashboards Settings). And you need at least one active Data Model Object actually mapped to a Data Lake Object and populated with data — the report type only appears for mapped DMOs. Verify all three before concluding the feature is broken; the failure is silent, with no error explaining the absent category.

Can you join Calculated Insights in a Data 360 report?

Not currently. You can join Data Model Objects together in a Data 360 report type, and you can report on a single Calculated Insight through its own report type — but you cannot join a Calculated Insight with other Calculated Insights or with DMOs in one report. Salesforce has indicated CI joins are planned, but build for today’s limitation: if a derived metric needs to appear alongside profile or transactional fields in a single report, model it as a DMO field, or handle the cross-insight analysis in a Calculated Insight that pre-joins the inputs or in Tableau Next.

Do Data 360 reports consume credits?

Effectively, yes. Unlike a report on a standard object, which runs against the Salesforce database, a Data 360 report runs against Data 360 storage through its query engine, and that engine is metered as consumption. Every report execution is a query, so heavily used dashboards with frequent auto-refresh can generate meaningful query volume. Control it by filtering reports tightly, snapshotting slow-moving metrics on a schedule instead of recomputing them on every load, and setting dashboard refresh to what the business actually needs.

---

Standing up Data 360 and want the reporting, governance, and credit economics designed together rather than discovered in production? Talk to us. Getting the data foundation right — so the unified data is trustworthy, reportable, and affordable to query — is exactly the work we do.