Import Configuration Reference
The import wizard's configuration step decides how a run of records enters the data pool: how the run is identified, which context its records belong to, whether it may replace what is already there, and how unknown columns are handled. This page is the reference the in-app help links into — one section per setting, with the consequences spelled out.
Importing is an administrative capability: it feeds the shared data pool that mock APIs read from. On the Enterprise plan the same controls apply to your tenant's own imports.
Import code
A short code that groups everything one logical import brings in — a batch identity, independent of file names.
Every record written by the run carries this code, which is what makes a re-import safe and precise: running the same import again with the same code affects exactly the records that code owns, and nothing else. Without a stable code, replacing "last month's load" would mean guessing by timestamp or file name.
| If you… | Then… |
|---|---|
| Reuse a code on a later run | that run updates/replaces the records the code owns (depending on the overwrite mode below) |
| Use a fresh code | the run lands as a new, independent batch alongside existing data |
| Leave it to a configuration preset | the preset's code is applied automatically |
Tags
The context every imported record is stamped with. At least one tag is required — imports without a tag are rejected, because untagged records would be invisible to the mapping and join rules that keep mock data coherent.
Tags are normalized (lower-cased, de-duplicated, sorted) into a tag group, and that tag group is the boundary inside which records relate to each other:
- The mapping picker only offers fields whose tags fit the target table's tag group — so a
Countrytable is never offered food-nutrition columns. - Relations resolve inside one tag group — a query never joins records across unrelated sources by accident.
Choose tags that describe the data's domain (for example geo, vehicles, food), not the technical source. The recommended tags shown by the wizard come from the source's analysis and are usually right.
Overwrite existing
Decides what happens when the run meets records that are already in the pool from an earlier import of the same scope.
| Setting | Behaviour | Use when |
|---|---|---|
| Off — enrich | existing records stay; the run fills gaps and appends new records | topping up a dataset, adding columns another source left empty |
| On — rewrite | the records owned by this scope (source / import code) are replaced by the run's records | the source published a corrected or fresher dump and the old rows should not survive |
Overwriting is scoped, never global: it replaces what this import's identity owns, and leaves every other source's records untouched. A dry run shows the would-be effect — including duplicate or missing merge keys — before anything is written.
Auto-create mock fields
Controls what happens when the run discovers columns that have no mock-field entry yet in the field catalog.
- On — every newly discovered data column is staged as a new mock field automatically (reserved, underscore-prefixed keys are skipped). The import keeps moving; the staged fields wait in the catalog for review and are published to the live catalog on approval. Nothing unreviewed reaches consumers.
- Off — unknown columns are imported as data but create no catalog entries; only columns already known to the catalog are usable in mapping until fields are created by hand.
Leave it on for new or evolving sources — it turns "the import failed because a field was missing" into "the import succeeded and left you a curation list". Turn it off for locked-down catalogs where fields must be designed before data may reference them.
Where these settings live
The wizard can save this configuration as a preset per source, so subsequent runs (and scheduled ones) reuse the same code, tags, and modes. The Data Sources page shows which preset a source uses; the causal effects of modelling decisions downstream of the import are catalogued in the Causality Reference.