Yellow keeps structure (schemas and models) separate from data (instances). One direct benefit: you can build and test a schema in a sandbox tenant, then promote the resulting structure to your production tenant without exporting and reimporting JSON by hand. This guide walks through that promotion.

When you need this

Common scenarios:

  • A new model has been designed and tested in Acme Staging. Once it is right, you want the same model — with the same UId, properties, constraints, and views — in Acme Production.
  • An existing schema gained a few new properties in staging. You want to roll those into production without touching the production data.
  • A whole schema is migrating ownership from a personal sandbox into the organization, then into the org's main tenant.

The schema-sync wizard

The promotion is performed by a Schema sync job — a system model that records what to copy, from where, to where. You configure one job per promotion.

From the organization page → Sync jobs → + New schema sync job:

  1. Source tenant — where the well-tested schema lives (e.g. Acme Staging).
  2. Target tenant — where the schema should arrive (e.g. Acme Production).
  3. Schemas to sync — pick one or more. You can promote them all together if they belong to the same feature area.
  4. Mode — typically additive (new models and properties are added in the target; existing items are reconciled by UId). Some setups also expose a replace mode that wipes the target structure first; use it with caution.
  5. (Optional) Dry run — runs the job, reports what would change, but does not commit. Always do this first.

Save and Run. The wizard reports each model and property it touched.

What the wizard does and does not do

It copies:

  • Models, properties, constraints, views.
  • Model and property UIds (so existing references in the target keep working).
  • System enumerations referenced by the schema.

It does not copy:

  • Instance data — the rows themselves. Use Copying data between tenants for that.
  • Per-tenant configuration — bookmarks, dashboard widgets, saved queries.
  • Role assignments — roles are per organization, not per tenant. Members keep whatever roles they had on the target.

A safe promotion sequence

For a real production tenant, follow this order:

  1. Freeze structural changes in production — make sure no one is editing the schema directly in the target while you sync.
  2. Run with dry-run on — read the diff carefully. Verify every property change is intentional.
  3. Take a snapshot — if your org keeps tenant snapshots, capture one of the target tenant before the live run.
  4. Run live — execute the sync.
  5. Validate — open the target tenant, browse a few key models, create a test instance, confirm forms render correctly.
  6. Unfreeze — let the team back into the target.

Versioning safety net

Because schemas are versioned (see Models), the previous shape stays on record after a sync. Existing instances in the target keep validating against the model version they were created with. If the sync introduces a property change you regret, you can re-run the wizard with a corrected source — or, in worst cases, ask a Yellow administrator to roll back the most recent version.