How-to

How to join datasets and create views in DataLens

The interesting questions almost always span two datasets. Joining them is how you get an answer neither one holds alone.

What you will do

You will join two or more datasets on the columns that relate them, choose the join type that matches the question you are asking, and save the result as a view the rest of the platform can use.

The join is designed visually and saved as a definition, not produced as a one-off export.

When this is useful

  • Customer attributes are in one system and transactions are in another.
  • You need a Customer 360 view assembled from CRM, billing and product data.
  • A reference table has the labels your fact table only has codes for.
  • You are checking whether two systems agree about the same entities.

Before you start

  • Two or more loaded datasets — From any source — uploads, database tables, CRM objects, lake files.
  • A join key that actually matches — A column present in both, holding the same values in the same form. This is where most joins go wrong.
  • Consistent key formatting — If one side has trailing spaces or different casing, standardise it in Prepare first. A key that looks identical and is not will silently produce no matches.

Steps

  1. Open Model → Create Views

    Select Model in the navigation, then the Create Views tab.

    This is the join designer. Views built here are definitions — they can be re-run rather than being a one-time output.

    A canvas where datasets can be placed and connected.

  2. Add the datasets you want to join

    Add the datasets to the canvas. Each appears as a node showing its columns.

    Nodes are typed by what they are — a raw dataset, a staged one, an existing view, a CRM object, a lake source or a data product — so a complicated join stays readable.

    One node per dataset, with column lists.

  3. Choose the join keys

    Connect the datasets on the columns that relate them. Pick the key deliberately: an ID that both systems genuinely share, not a name that happens to look similar.

    A join on a formatted name field is the classic cause of a join that returns almost nothing.

  4. Choose the join type

    Inner keeps only rows that match on both sides. Left keeps every row from the left dataset and fills in what matches. Right does the reverse. Outer keeps everything from both.

    The choice is a question about your data, not a technical preference. "Which customers have no orders?" is a left join. "What did customers who ordered actually buy?" is an inner join.

  5. Check the result

    Look at the resulting row count and a sample of rows. A join that produced far fewer rows than expected means the keys did not match; far more means the key was not unique on one side and you produced a fan-out.

    Both failures are silent unless you look, which is why this step is not optional.

    A row count and sample rows that are consistent with what you expected.

  6. Save the view

    Name and save the view. It becomes available across the platform — chart it in Analyse, publish it in Deliver, or use it as a node in further modelling.

    The view listed alongside your datasets, usable wherever a dataset can be used.

What happens next

A saved view can be charted, published, exported or used inside a data product. It can also feed another view, which is how a Customer 360 gets built up in layers rather than in one enormous join.

Where the join is part of a repeating process, put it in a pipeline in Orchestrate so it runs on a schedule.

Example

A team wants win rate by industry. Industry lives on the Account object and outcome lives on the Opportunity. They add both to Create Views, join on AccountId with an inner join, confirm the row count matches the opportunity count, and save it as "Opportunities with industry". Analyse charts it directly.

Tips

  • Standardise the key columns in Prepare before joining. Casing and whitespace differences produce a join that returns nothing and explains nothing.
  • Always check the row count after joining. It is the fastest detector of both a failed join and an accidental fan-out.
  • Left join to find what is missing. It is the join that answers "which of these has no matching record?".
  • Build in layers. Two readable views beat one join across six datasets that nobody can debug.
  • Name views for what they contain, not for how they were made.

Limitations

  • Four join types are available: inner, left, right and outer.
  • A join needs a key column with matching values. There is no fuzzy or approximate matching between similar-but-different values.
  • A non-unique key on one side produces a fan-out — more rows than either input. That is correct join behaviour, not a bug, but it is rarely what was intended.
  • A view is a definition over datasets in DataLens. It does not create a view in your source database.

Related questions

More of these on the DataLens FAQ page.

Can I join data from different source systems in DataLens?

Yes. Once loaded, a CRM object, a database table, an uploaded file and a lake file are all just datasets, and any of them can be joined with any other on a shared key. That cross-system join is usually the reason to bring the data together in the first place.

Which join types does DataLens support?

Inner, left, right and outer. Inner keeps only matching rows; left and right keep everything from one side; outer keeps everything from both.

My join returned far more rows than either dataset. What happened?

The join key is not unique on at least one side, so each row on one side matched several on the other — a fan-out. It is correct join behaviour. Either use a key that is unique, or aggregate the many-side first.

Try this in DataLens

DataLens is in private beta. Request access and work through this guide on your own data.

Request beta access