Skip to main content

Bridging from Marketing Cloud SQL: a crosswalk to Data 360's query surfaces

A practitioner's crosswalk for the Marketing Cloud SQL veteran: each MC SQL pattern you already know, its Data 360 equivalent, and where the instinct quietly misleads. Assumes the dialect — links to it rather than re-documenting it.

Reference·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

You already write SQL against Data Extensions in Marketing Cloud. Data 360 (formerly Data Cloud) also speaks SQL, and that overlap is the most useful thing you bring and the most dangerous. Useful, because SELECT … FROM … JOIN … WHERE … GROUP BY reads the same. Dangerous, because the architecture underneath is different enough that a handful of MC reflexes carry you most of the way, then drop you — silently, the way a query that parses but answers the wrong question always does.

This page is the crosswalk: the MC SQL pattern you know, its Data 360 equivalent, and where the instinct misleads. It assumes the dialect reference rather than repeating it — for the function list, the object naming, and the syntax, see Data Cloud SQL dialect. Here the subject is the translation, and the one structural fact every row below restates: Marketing Cloud SQL is a write tool (an Automation Studio activity that builds Data Extensions), and Data Cloud SQL is a read surface over a model you built elsewhere.

The crosswalk

| Marketing Cloud SQL | Data 360 equivalent | Where the instinct misleads | | --- | --- | --- | | System Data Views — _Subscribers, _Sent, _Open, _Click | No equivalent. Query DMOs over the unified profile (UnifiedIndividual__dlm and engagement DMOs) | There is no canonical engagement table to FROM. You query the model you mapped, not a system view Salesforce maintains for you | | INSERT INTO <DE> SELECT … activity wrapper | Read-only SELECT. Pre-compute with a Calculated Insight, or read with the Query API | SQL does not write rows back. Reaching for a destination DE finds nothing to point at | | Overwrite / Append / Update target action | Not a SQL concept. A CI's refresh defines its output; the Query API just returns rows | There is no "target action" to pick. The write semantics you decided before writing MC SQL have no analog here | | T-SQL function subset (DATEADD, LEN, ISNULL, GETDATE()) | ANSI-leaning functions; names and signatures differ | DATEADD(day, -30, GETDATE()) is muscle memory that misfires. Check the dialect page before porting any date or string call | | SubscriberKey + defensive string-cast joins | The DMO primary key + the identity-resolved unified individual, one layer up | You don't hand-join string keys to stitch a person together. Identity resolution already did it; you query the result | | Staging DE → promote (two-step rebuild) | Not applicable. The model plus Calculated Insights replace the pattern | There is no de_stg_ to build and swap. Pre-computation lives in a CI, defined once, not in a staged write you orchestrate | | 30-minute SQL Activity hard timeout | Query API async + pagination; CI refresh cadence | The failure surface moved. It's now "did the caller page through nextBatchId" and "how stale is the CI," not "did the activity beat the clock" |

The five reflexes worth unlearning, in detail

System Data Views have no successor

In Marketing Cloud, _Sent, _Open, and _Click are where engagement lives, and _Subscribers is the spine you join everything to. The instinct is to look for the Data 360 equivalent. There isn't one. Engagement in Data 360 is whatever you ingested and mapped into engagement DMOs, and the spine is UnifiedIndividual__dlm — the resolved profile, not a subscriber table. (Standard DMOs carry the ssot__ prefix, e.g. ssot__Individual__dlm; match whatever your org's model uses.)

The deeper shift: System Data Views were given to you. The Data 360 profile is built by you — through ingestion, mapping, and identity resolution. A query that finds the engagement object empty is usually pointing at a modeling gap upstream, not a query bug. That MC-side caution about views silently emptying (MC SQL gotchas, gotcha 6) has no direct echo, but its lesson does: know exactly which object you're reading and where its data comes from.

SQL doesn't write rows here

The single biggest reflex to drop. Every production MC SQL query you've shipped ends, implicitly, in a write — the Automation Studio activity wraps your SELECT in INSERT INTO <destination> SELECT … (MC SQL basics). Data Cloud SQL has no wrapper and no destination. It is read-only.

So the question "where do I write the result" splits into two, and you pick before you write a line:

  • A metric many consumers retrieve — lifetime value, an engagement score, an order count per person → a Calculated Insight, computed once and served everywhere. This is the closest thing to "build a Data Extension once and let everyone read it," done right.
  • An ad-hoc pull for an export, an analysis, an integration → the Query API, which runs the SELECT and returns rows to your caller. Nothing is persisted.
-- Marketing Cloud habit: the activity writes this into a destination DE.
-- The whole point is the write.
INSERT INTO send_audience
SELECT s.SubscriberKey, s.EmailAddress, s.LoyaltyTier
FROM _Subscribers s
WHERE s.Status = 'Active';

-- Data 360: the same shape is read-only. It returns rows; it persists nothing.
-- If many consumers need this, define a Calculated Insight instead of re-running it.
SELECT i.ssot__Id__c, i.ssot__FirstName__c
FROM UnifiedIndividual__dlm i
WHERE i.ssot__FirstName__c IS NOT NULL;

The function subset changed shape

MC SQL is a strict T-SQL subset; Data Cloud SQL is ANSI-leaning. The overlap is wide enough to lull you — COUNT, SUM, GROUP BY, CASE, LIKE all behave — and the gaps are exactly the dialect-specific calls you reach for without thinking. DATEADD, GETDATE(), ISNULL, LEN are the usual suspects: the T-SQL spellings you'd port on autopilot, where the Data 360 equivalent has a different name or signature.

The rule is small and saves an afternoon: do not port a date or string function from memory. Look it up on the dialect page first. The MC habit of leaning on DATEADD(month, -3, …) was already fragile across year boundaries (MC SQL gotchas, gotcha 8); here it's not fragile, it's a different function entirely.

SubscriberKey discipline moves up a layer

In MC, joining a person across Data Extensions is your job, and it's finicky: SubscriberKey is a string, leading zeros and trailing whitespace bite, and the safe join casts and trims both sides (MC SQL gotchas, gotcha 9). That entire discipline — stitching one person together from many key-matched rows — is what identity resolution does in Data 360, before your query runs.

So you don't hand-join string keys to assemble a customer. You query UnifiedIndividual__dlm, which is the assembled customer. The discipline didn't disappear — it moved up a layer and changed owners. What you still own is choosing the DMO primary key well, with the same care you gave SubscriberKey: it decides deduplication and joins, and changing it after resolution has run is a rebuild, not an edit (see Data 360 principles). And one new reflex replaces the old one — know whether you're counting unified individuals or source rows, because they won't match, by design (Query & Insights gotchas, gotcha 9).

The timeout moved; it didn't leave

The 30-minute SQL Activity timeout is the MC failure you build around from day one (MC SQL gotchas, gotcha 3): split anything that risks it into staged activities. Data 360 doesn't have that clock, which is a relief right up until you assume the failure mode left with it. It just moved.

The shape of the move, in one contrast

-- MARKETING CLOUD: a write, orchestrated in two steps to survive the timeout.
-- Stage, then promote. The result is rows that live in a Data Extension.
INSERT INTO de_stg_ltv
SELECT SubscriberKey, SUM(OrderTotal) AS LifetimeValue
FROM purchase_history
GROUP BY SubscriberKey;
-- (a second activity then promotes de_stg_ltv into the production DE)

-- DATA CLOUD: no staging, no write, no promote. The aggregation is a
-- Calculated Insight, defined once at the right grain. Consumers RETRIEVE it;
-- they never recompute it. The "two-step rebuild" pattern simply dissolves.
SELECT
  o.ssot__BuyerId__c                AS buyer,          -- dimension: the grain
  SUM(o.ssot__GrandTotalAmount__c)  AS lifetime_value  -- measure
FROM ssot__SalesOrder__dlm o
GROUP BY o.ssot__BuyerId__c;

The contrast is the whole page in miniature: same SQL silhouette, opposite center of gravity. MC SQL orchestrates a write and you defend it against a timeout. Data Cloud SQL defines a read — once, as a Calculated Insight, at a grain that has to be right because every consumer inherits it (Query & Insights gotchas, gotcha 5).

Related

Reference: