Integration keys on import

When you import metadata, DeltaVault can build your business keys for you. Instead of designating a business key column on every source table by hand, an import can infer the key from each table’s primary key (or from the business-key columns you flagged), build one integration-key column per table at the Staging layer, hash from that key, and even repoint foreign-key relationships onto it. This is the automated counterpart to a business key column you designate yourself.

Turn it on

The defaults live in Settings, in the Data Vault section, on the Integration keys on import card. The card has three controls:

Create concatenated business keys is the master toggle. It is off by default. Leave it off and imports behave exactly as before: no integration keys are built and nothing about your imports changes.
Infer business key from chooses where the key comes from: Primary Key or Manual (described below).
Apply to relationships repoints foreign-key relationships onto integration keys (described under Apply to relationships).

Two settings that shape the key value itself live elsewhere, in the Shared section rather than on this card, and they act on the business key hash rather than on the integration key column:

Prepend record source to the business key hash puts the resolved record source in first position in every business key hash, so the same natural key from two different sources stays distinct. The record source is resolved per project. Existing keys keep their own stored choice, so changing this sets the default for newly designated keys only.
Pad the business key hash to the maximum identifier length pads every business key hash out to the naming profile’s maximum identifier length. Changing it rehashes every business key in every staging build, so the next load reads every existing row as a genuine change once.

The card is available at both the organization and the project scope, so you can set a default for the whole organization and override it on a project that needs different behavior.

Override it for one import

Each import can override the two key-building controls for that run. In the import review step, the Integration keys section is pre-filled from your resolved settings and lets you change, for this import only:

Create concatenated business keys (the master toggle), and
Infer business key from (Primary key or Manual).

Apply to relationships is not in the per-import section: it stays as you set it on the settings card, as do the two Shared-section hash settings above. For any control, the value that applies to an import is the per-import override when you set one, otherwise the project or organization setting, otherwise the factory default.

Primary Key or Manual

Primary Key mode designates each source table’s primary-key columns as its business key and builds one integration key from them. This is the common case for a database import, where the primary keys come through with the schema.
Manual mode uses the columns you already flagged as business keys. Flagging business-key columns is available on the delimited-upload and file-discovery paths, so Manual mode suits those imports where you curate the key columns yourself.

A source table with no key to infer from is simply skipped: it gets no integration key.

What you get at Staging

For each source table that gets a designation, the import builds one integration-key column at the Staging layer. Its name follows your business key column pattern (default {{this}}_BK, so a table named Customer yields a column Customer_BK) and its value is the designated columns joined with the business key separator (default ||), with business key normalization applied to each part. The mechanics mirror a business key column you designate by hand, so see Business key column for how a designated key is built from its columns, including derived keys with transforms.

Two import-time options shape the value further:

Prepend record source to the business key hash, when on, puts the resolved record source in first position, so the same natural key from two different sources produces two distinct hashes.
Pad the business key hash to the maximum identifier length, when on, pads the hash out to the naming profile’s maximum identifier length, so fixed-width keys line up.

When integration keys are on, the Staging change hash is computed from the single integration-key column rather than from the separate raw key columns, so the hash tracks the one key you actually load on.

The integration-key SQL generates for Databricks and Microsoft Fabric.

Apply to relationships

Turn on Apply to relationships (on the settings card) and an import does more than build each table’s own key: it lines up the keys across related tables.

For every child table whose parent has an integration key, the import builds a foreign integration-key column on the child’s Staging table. It concatenates the child’s foreign-key columns in the same order as the parent’s key, with the same separator and normalization, so the child value matches the parent key exactly. The relationship is then repointed onto the parent’s integration key, and the original raw foreign-key reference is cleared at Staging, because the relationship is now expressed on integration keys.

A few cases are handled automatically:

Composite foreign keys (more than one column referencing the parent) are grouped into a single foreign integration key.
More than one foreign key to the same parent, or a self-reference (a table that points at itself, such as an employee’s manager), gets role-prefixed column names so they do not collide, for example ShipTo_Customer_BK and BillTo_Customer_BK.
A relationship whose parent has no integration key is left alone.

Apply to relationships is off by default and only takes effect on import when the setting is on.