Stage

Applies to
Platform: Microsoft SQL Server · Snowflake · Snowflake dbt · Databricks · Databricks dbt · Fabric Lakehouse · Fabric Warehouse · Oracle
Architecture: Stage · Data Store · Data Vault · Dimensional

A Stage copies the data of a source object into the Stage layer, as a table that each load refills or as a view on the source. Use one Stage for each source object that your solution reads. The model objects of the next layer read the result view of the Stage.

Sources and relationships

A Stage reads Sources in exactly one dataflow. It has no relationships. These model object types read a Stage:

Data Store: Store Entity and Store Composite.
Data Vault: Hub, Link, Same As Link, Hierarchical Link, Driving Key Link, all Raw Vault satellite types, RawVault Composite and Reference Table.
Dimensional: Entity, Fact and Core Composite.

Create a Stage

From a Discovery of the source system: see Create Source Objects from a Discovery.
With the wizard: open the menu of a Source, choose Automate and then Create Stage. Its steps are Create Model Object, Map Terms and Add to View. See Create a Model Object with the wizard.
Manually: create a model object of type Stage in the Stage layer, create a dataflow set, add the Source and map the terms.

Properties

Implementation Type: Cached (default) stores the data in a table that the loader empties and refills on every load. Virtual creates only views on the source object. The Stage Files, OpenQuery and JDBC generators do not offer Virtual.
Deduplication Method: None (default), Distinct or Partition, with Sort Order within Partition. OpenQuery offers None and Distinct. A method other than None adds a deduplication view. Validation then reports a warning, and generation continues: Model object '<model object name>' of type 'Stage' has deduplication method 'Distinct' or 'Partition' configured.
Increment Management Type: Auto (default) or User, see Configure an incremental load. The Stage Files and JDBC generators of Databricks and Fabric Lakehouse and the Snowflake Stage Files generator offer Auto only. Available since Generator 2.2.

Default Terms

BG_LoadTimestamp: the timestamp of the load that wrote the row.
BG_SourceSystem: the source system of the row; empty unless you map it.
BG_IncrementalFilter: mapping it to a source term switches the Stage to an incremental load.
BG_ID, BG_DataflowName and BG_DataflowSetName: columns of the increment table.
BG_LowerThreshold, BG_UpperThreshold and BG_IncrementLoadStatus: hidden terms of the incremental load, not on Snowflake dbt and Databricks dbt.
Databricks and Fabric Lakehouse Stage Files also carry BG_SourceFilePath and BG_CorruptedRecord.

Generated objects

These are the names on Microsoft SQL Server for a Stage customer:

Role	Generated name	Purpose
Source	`STG_ST_customer_Source`	Reads the source object
Deduplication	`STG_ST_customer_Deduplication`	Removes duplicate rows
Increment	`STG_ST_customer_Increment`	Stores the increment thresholds
Loader	`STG_ST_customer_Loader`	Empties and refills the table
Storage	`STG_ST_customer`	Stage table
Result	`STG_ST_customer_Result`	View read by the next layer

The loader is a stored procedure; STG_ST_customer and the increment table are tables; all other objects are views.
The deduplication view exists only with a Deduplication Method other than None.
The increment table exists only with an incremental load. Its last threshold restricts the source view to newer rows.
With Virtual, only the source, deduplication and result views exist.
Microsoft SQL Server Stage Files: the raw-data table STG_ST_<model object name>_RawData, its loader _RawDataLoader and a format file per Stage read the file. The Stage table and its loader exist only with an incremental load; otherwise the result view reads the source view.

With all optional objects, the dependencies are:

source object -> _Source -> _Deduplication -> _Loader
_Loader -> STG_ST_customer -> _Result -> next layer
_Increment -> _Source (incremental load only)

Without a Deduplication Method, the loader reads _Source directly.

Example

The Stage branch on Microsoft SQL Server reads the source table BRANCH with the default Cached. Load 1 on 2026-10-28 delivers the branches 1 Basel large, 2 Bern small and 3 Zurich large. Before load 2 on 2026-10-29, the source deletes branch 3 and changes the market size of Bern to large.

Check the result

Query the result view after load 2, here in the schema stg:

SELECT BRANCH_ID, BRANCH_NAME, MARKET_SIZE, BG_LoadTimestamp
FROM stg.STG_ST_branch_Result
ORDER BY BRANCH_ID;

The result, with the timestamp shortened:

BRANCH_ID  BRANCH_NAME  MARKET_SIZE  BG_LoadTimestamp
1          Basel        large        2026-10-29 08:00
2          Bern         large        2026-10-29 08:00

The loader replaced all rows, so Zurich is gone and both rows carry the timestamp of load 2.
After load 1 the view showed three rows with the timestamp 2026-10-28 08:00.

Platform differences

Snowflake: names are in capitals, and the Stage table is a transient table. The load control task LC_STG_ST_<model object name>_TASK calls the loader. The dataflow properties Use Stream and Warehouse Placeholder Variable Name apply.
Databricks and Fabric Lakehouse: the loader is the notebook STG_ST_<model object name>_Loader. The properties File Format, Optimization Method and Optimization Method Columns apply. Stage Files add the term property Partition Filter.
Snowflake dbt and Databricks dbt: the generator creates the dbt models stg_st_<model object name>_source (view), stg_st_<model object name> (table) and stg_st_<model object name>_result (view). Increment Management Type is not available.
Fabric Warehouse: the same objects as on Microsoft SQL Server.
Oracle: names are in capitals, and the loader is a PL/SQL package. An incremental Stage with Auto adds the view STG_ST_<model object name>_INCREMENTSOURCE. Physical properties such as Partition Clause, Table Compression and tablespaces apply.

Limitations

A Stage has exactly one dataflow and no relationships.
A Virtual Stage cannot load incrementally. Validation reports: Model object '<model object name>' of type 'Stage' has implementation type 'Virtual' and incremental load defined.
A Stage cannot be historized; it has no validity terms.