A Dimension can keep every earlier version of its records, not only their current values. With Store History on, each change writes a version you can read back. Turning the toggle on or off is on Dimension and fact general settings, inside the table editor described on Create a dimension or fact table.
With Store History on, the Dimension gets a second table that holds its versions: the Dimension's structure, with one row per version of each record. It is named after the Dimension with History added, so a Dimension called Customers has a table called Customers History. It appears in table lists, for example in the SQL editor's schema.
A version row carries all of the Dimension's columns, plus the columns that describe the version:
| Column | What it shows |
|---|---|
| Valid From | When this version of the record became the current one. |
| Valid To | When it stopped being current. The current version's Valid To stays open, far in the future. |
| Is Latest | True for the version that is current now. |
| History Delete Flag | Always false. |
| History Update DateTime | When the version was written. |
These are system columns, so they stay locked: you cannot rename or remove them. In the table editor they show up in the Columns step while Store History is on; Define table columns covers the column grid.
Each history run compares the Dimension's records with the versions already stored for the source system it loads. A record counts as changed when its mapped columns, its key or its Delete Flag differ from the stored version.
A Dimension with Store History has an extra history step in its workflow, next to the transformation that loads the table. It runs when the workflow runs, and it needs the table to be a deployed Dimension with Store History on, and the source system to have a transformation with its schedule on. When something is missing, the step is skipped and shows the reason:
A history run also stops when the table is not a deployed Dimension with Store History on, naming the problem: Table X does not have store_history enabled, Table X is not deployed, or Table X is not a Dimension table (type: Y).
To start the table's loads and watch them, see Deploy, run, truncate and monitor tables.
Because it is still the current version. Its end is left open far in the future, and Is Latest is true for it. When the record changes, the run closes this version and opens a new one.
The run closes the record's previous version and opens a new one at the run's date. The new version becomes the current one; the previous version now reads as a closed interval.
Nothing is written for that record. The run compares it with the stored version and leaves it alone when the mapped columns, the key and the Delete Flag all match.
It is part of the table's workflow and runs with it. For it to load, the source system must have a transformation with its schedule on, and the table must be a deployed Dimension with Store History on.
The reason on the step names what is missing: Table does not exist, Table is not dimension, Table is not deployed, Table has not store_history enabled, Source system doesn't exist in relation or Schedule active etls does not exist. For Skipped Due To Previous Error or Node Already Run, see Skipped runs and restarts.
When the table is not a deployed Dimension with Store History on, the run stops and names the problem: Table X does not have store_history enabled, Table X is not deployed, or Table X is not a Dimension table (type: Y). Fix the named state on the table, then run again.
No. On a Dimension with history, the Truncate Target choices split the work: Main clears the current table data only, History clears the versioned data, and All clears both. See Dimension and fact settings.
Yes. It sits beside your other tables in table lists, for example in the SQL editor's schema, and its version rows can be selected and filtered like any other table's rows.
They are the history table's bookkeeping columns. Every version is written with History Delete Flag false, and History Update DateTime records when the version was written. Both are system columns and stay locked.
A version is written only when a record changes, so records that change often collect more versions than records that rarely change.