A Data Model can pick which source or transform output a view should read — but it cannot combine two tables. The moment a dashboard needs "orders joined with customers" or "this year's data unioned with last year's," the correct tool in BI Portal is a Flow, not a workaround inside a Model.
The node types that matter
- Source — reads a Data Source or Model, Live or from cache; every flow starts here
- Join — combines two inputs side by side on matching keys; has separate Left and Right inputs, both required
- Union — stacks two tables with the same column shape, growing rows instead of columns; used for period-over-period or branch-over-branch combinations
- Transform / Steps — reuse a source's defined transforms, or apply small flow-specific cleanup inline
- Filter and Aggregate — narrow rows (often right after a Join, before a row-count explosion becomes a problem) and produce group + measure summaries
- Sink Data Source — writes the flow's output as a new, reusable Data Source; Sink Mail — emails the result as a CSV attachment instead
Join vs Union, the distinction that causes the most support tickets
A Join widens columns and depends on a correct key match — the classic failure is a wrong or duplicate key producing a row-count explosion, or an inner join silently dropping unmatched rows. A Union grows rows and depends on column name/type alignment — the classic failure is a column mismatch that either errors out or quietly nulls a field.
Why it matters
Before Flows, "combine these two SAP sources" meant a custom ABAP report, a separate ETL tool, or a manual Excel merge redone every week. Building the join or union visually, inside the same BI Portal session that will publish the resulting dashboard, removes an entire integration project from the timeline — and keeps the combined data governed by the same refresh jobs and role checks as everything else.