What is a dataset in CRM Analytics, and why does the platform use its own storage format?

A dataset is combined data from one or more related objects, stored in a compressed, query-optimized format built specifically for analytics. It uses a flattened, inverted-index, key-value store, which lets it hold large volumes of data and still return dashboard queries in sub-second time. That combination of big data and fast interactive querying is why it doesn't just query Salesforce directly.

What is grain, and why is it the first thing you decide when building a dataset?

Grain is what a single row of the dataset represents — one opportunity, one case, one account. You decide it first because it determines which object you start from and how you bring in related data. Get the grain wrong and your measures multiply or your dataset answers the wrong question. A good sanity check is to finish the sentence 'one row of this dataset is one ____.'

Why do you start Dataset Builder from your lowest-grain object?

Because Dataset Builder only lets you look up the relationship tree. Start with Opportunity and you can reach up to its Account and its owning User. Start with Account and there's nothing above it to reach, so you're stuck with one row per account. The object you start with is a deliberate design decision driven by what the dataset is about.

What's the difference between a lookup and a join, and why does it matter?

A lookup attaches parent fields onto each child row without changing the grain — one opportunity stays one row, now carrying account fields. A full join can match many-to-many and multiply rows, which inflates sums if you didn't intend it. When a total looks too large, check the grain first; it's usually a lookup that behaved like a fan-out join.

Compare Dataset Builder and recipes for building a baseline dataset.

Dataset Builder is guided: it walks the Salesforce relationships, auto-detects join keys, and writes a dataflow — lookups only, hard to get wrong, great for beginners. Recipes are drag-and-drop and far more flexible, but you choose the objects, join types, and keys yourself, so you own both the power and the mistakes — for example, it may guess the wrong join key and match Opportunity ID to User ID instead of Owner ID.

What are the Connect/Sync layer and the dataset layer, and how do they relate?

Connect (Sync) is a staging area that pulls raw Salesforce and external objects in as-is, with scheduled and incremental refresh. Dataflows and recipes then read from that staging layer to build the finished datasets your dashboards consume. Dataset Builder and recipes read from sync, not from Salesforce directly — which is why an object must be synced before you can use it.

A dataflow fails the first time you run it in a new org. What's your first check?

That the source objects are actually in the sync layer. The dataflow reads from Connect, not from Salesforce, so if Account, Opportunity, and User haven't been synced yet, it has nothing to read and errors out. The fix is to run Connect manually once to stage the data, then re-run the dataflow. When everything is scheduled correctly this happens automatically.

When combining two datasets in a recipe, what must you not forget, and how do you keep the data fresh?

You must add an output (register) node — the joins produce nothing usable until you output the result. For freshness, respect the order of operations: sync refreshes the base objects, the baseline dataflow or recipe rebuilds the source datasets, then the combining recipe rebuilds the final dataset. Schedule them in that sequence or the final dataset serves stale data.

Creating Datasets: Interview Questions

Interview questions

8 common questions with model answers — rehearse each one aloud.

1
What is a dataset in CRM Analytics, and why does the platform use its own storage format?
A
A dataset is combined data from one or more related objects, stored in a compressed, query-optimized format built specifically for analytics. It uses a flattened, inverted-index, key-value store, which lets it hold large volumes of data and still return dashboard queries in sub-second time. That combination of big data and fast interactive querying is why it doesn't just query Salesforce directly.
2
What is grain, and why is it the first thing you decide when building a dataset?
A
Grain is what a single row of the dataset represents — one opportunity, one case, one account. You decide it first because it determines which object you start from and how you bring in related data. Get the grain wrong and your measures multiply or your dataset answers the wrong question. A good sanity check is to finish the sentence 'one row of this dataset is one ____.'
3
Why do you start Dataset Builder from your lowest-grain object?
A
Because Dataset Builder only lets you look up the relationship tree. Start with Opportunity and you can reach up to its Account and its owning User. Start with Account and there's nothing above it to reach, so you're stuck with one row per account. The object you start with is a deliberate design decision driven by what the dataset is about.
4
What's the difference between a lookup and a join, and why does it matter?
A
A lookup attaches parent fields onto each child row without changing the grain — one opportunity stays one row, now carrying account fields. A full join can match many-to-many and multiply rows, which inflates sums if you didn't intend it. When a total looks too large, check the grain first; it's usually a lookup that behaved like a fan-out join.
5
Compare Dataset Builder and recipes for building a baseline dataset.
A
Dataset Builder is guided: it walks the Salesforce relationships, auto-detects join keys, and writes a dataflow — lookups only, hard to get wrong, great for beginners. Recipes are drag-and-drop and far more flexible, but you choose the objects, join types, and keys yourself, so you own both the power and the mistakes — for example, it may guess the wrong join key and match Opportunity ID to User ID instead of Owner ID.
6
What are the Connect/Sync layer and the dataset layer, and how do they relate?
A
Connect (Sync) is a staging area that pulls raw Salesforce and external objects in as-is, with scheduled and incremental refresh. Dataflows and recipes then read from that staging layer to build the finished datasets your dashboards consume. Dataset Builder and recipes read from sync, not from Salesforce directly — which is why an object must be synced before you can use it.
7
A dataflow fails the first time you run it in a new org. What's your first check?
A
That the source objects are actually in the sync layer. The dataflow reads from Connect, not from Salesforce, so if Account, Opportunity, and User haven't been synced yet, it has nothing to read and errors out. The fix is to run Connect manually once to stage the data, then re-run the dataflow. When everything is scheduled correctly this happens automatically.
8
When combining two datasets in a recipe, what must you not forget, and how do you keep the data fresh?
A
You must add an output (register) node — the joins produce nothing usable until you output the result. For freshness, respect the order of operations: sync refreshes the base objects, the baseline dataflow or recipe rebuilds the source datasets, then the combining recipe rebuilds the final dataset. Schedule them in that sequence or the final dataset serves stale data.

Discussion

No comments yet — be the first to start the discussion.