New BI Portal designers often reach for a Data Model when they actually need a second Data Source, or try to join two tables inside a Model when that logic belongs in a Flow. The distinction is simple once stated directly: a Source prepares data, a Model chooses which output of it to expose, a View consumes the Model.
What each layer owns
- Transforms are defined only on the Data Source — never on the Model
- A Model selects which parent source, and which source transform output (or the raw output), a view should read — nothing more
- Joining two tables is not a Model operation — that is what a Flow's Join node exists for
Creating a Model correctly
- Start a new Data Model and select the parent Data Source — this choice is locked after creation
- Accept or edit the generated Object ID (
MDL_...) - Optionally select a Source Transform; otherwise the Model reads the raw source output
- Save, then preview with either Live (for non-file source types) or Cache
An empty preview after this setup almost never means the Model is broken — it means the parent source's cache has not been filled yet by a refresh job. Run the source job first, then re-check the Model.
Why it matters
Keeping this boundary clean means a Data Source can be reused by several Models and Flows without duplicating connection logic, and it means troubleshooting an empty view starts at the right layer — the parent Source's cache — instead of a designer assuming the Model itself needs to be rebuilt.