Every instance list can be turned into a file, and a file can be turned back into instances. The same export works as a backup, as a way to move data between tenants, and as a seed file an administrator applies automatically. This walkthrough covers both directions.

Exporting

Open a model's instance list and click Export in the toolbar. The menu offers the current results in two formats:

  • Export results (JSON) — the full result of your current search: the active filter, the sort order, and the include deleted flag all apply. This is the format Yellow can read back.
  • Export results (CSV) — the same rows as a spreadsheet file. Open it in Excel or import it into another tool. CSV is for reading, not for importing back into Yellow.

Pick a format, choose where to save the file, and you're done. The suggested filename carries the model's name.

Exporting a selection

When you only want some rows, switch on Multiple selection — the small checklist button at the left of the count bar, just under the toolbar.

  1. Click the checklist button. A checkbox appears on every row.
  2. Tick the rows you want. The checkbox at the very left of the count bar selects or clears every loaded row at once, and a badge shows how many are selected.
  3. Open Export again — two new entries appear: Export selection (JSON) and Export selection (CSV), with the count.

The selection survives paging and filter changes, so you can collect rows from several searches before exporting. Switching the mode off clears it.

What's inside the files

Format One row is… Good for
JSON the complete instance, with every property and its identifier importing back, transferring between tenants, seed files
CSV one line, one column per property spreadsheets, reports, sharing with people

A JSON export belongs to one model — the file records which one. Instances keep their identifiers, which is what makes re-importing safe: Yellow can tell "this row already exists" from "this row is new".

In the CSV, a Localized String property becomes one column per language (Name [ca], Name [en], …), references show the text you see on screen, and collections are joined with ;.

Importing

Importing reads a JSON export back into the same model. Open that model's instance list, click ExportImport from file… and pick the file.

If the file belongs to a different model, Yellow tells you and stops — open the right model's list instead.

Next, choose what happens to instances that already exist:

Mode If the instance already exists If it's new
Create only left untouched, counted as skipped created
Create and update gets a new version with the values from the file created
Duplicate — every instance is imported as a copy with a new identifier created

Create and update is the usual choice when bringing data back after editing it elsewhere, or refreshing a tenant with a newer export. Create only is the safe choice when you only want to fill gaps. Duplicate is for cloning rows on purpose.

Click Import. The import is all-or-nothing: either every instance in the file is applied, or — if anything fails — nothing is, and a dialog lists what went wrong and at which position in the file. Fix the file and try again.

After a successful import the list refreshes and a message shows the counts: created, updated, skipped.

Things worth knowing

  • References travel by identifier. A reference inside the file points at its target instance. Targets that are also in the file are resolved automatically, in any order. Targets outside the file must already exist in the tenant, or the import reports an error.
  • Updates create versions. "Create and update" never overwrites silently — the previous values remain in the instance's version history.
  • Permissions apply. Exporting needs permission to list the model's instances; importing needs permission to create them (and to update them, for "create and update").