Create tables with Ronja

Who can do this

Creating tables this way requires Build mode access, enabled per account by an administrator (see Standard, Deep analysis, and Build). Committing changes to a shared table requires Admin, or a maintainer of its feature — everyone else submits a draft for review.

You don’t write SQL to create a table in Ronja — you describe it in a Build-mode conversation, review the draft privately, and publish when it’s right.

Build a new table

1. Click New Exploration.
2. Select Build on the start screen (shown only when Build mode is enabled for your account).
3. Describe the table you want. Ronja’s own hint on a new table reads: “Describe what you want to see in the chat, and I’ll find the right data sources and build the table for you.”
4. Review the draft Ronja builds. A Derived table is “Built from other tables as inputs with SQL”; a Dynamic table is “Written to directly by agents as they run” — see Table types.
5. Iterate in plain language until the preview looks right. While it’s a draft, only you can see it.

Tip

Say exactly what the table should contain, and read the Plan Ronja writes before she builds. Getting the shape right in the plan produces a better table and spends fewer credits than reworking a built one.

Commit the draft

The table’s detail page shows a draft banner with three actions — on your own private table, or as an Admin; non-admins on a shared table see Read-only here and go through review instead (see the caution below):

1. Click Publish to make the table live — the confirmation modal is titled Commit Changes. The button stays disabled until the table has built (“Build the table first before publishing”).
2. Click Save as New instead to keep the original untouched and branch your changes into a separate copy, “{name} (Copy)” — useful when you’re experimenting and don’t want to change the table everyone else uses. The prefilled name is one you’re choosing, so it has to follow the naming rule: if the table you’re branching from has a full stop in its name — connectors and pipeline files can create those — the copy is refused until you take the dot out.
3. Click Discard to throw the draft away.

The draft banner on a table you’re editing.

Caution

Committing a shared table publishes it for everyone who uses it. If you’re not an admin, edits to a shared table don’t go live directly — the table shows Draft pending review and an Admin reviews the change before committing it.

You hold one draft per table; trying to start a second gives “A draft already exists for this table”.

Rebuilds

Derived tables rebuild themselves automatically when the data in an input table changes — an input finishing a build, or rows written to or restored into a Dynamic table. You don’t have to trigger it, and the change flows on to whatever is built on top of the derived table in turn. The one exception is a script that sends several tables over the API and holds their rebuilds back until it has sent them all: the Derived tables built from those wait for the script to release them, or about 15–20 minutes at most, and then rebuild once (see Send several tables at once). A table built from several inputs waits until all of them have caught up with the change and then rebuilds once, over everything new; while it waits it reads Ready with no banner, and the Data map’s Builds lens shows it as waiting on an input. It also waits, at most about 15–20 minutes, for an input whose sender is still sending related tables, so that it doesn’t rebuild over half of that batch. If a table is due a rebuild it hasn’t run yet, its page shows This table’s data is stale, with a rebuild action for Admins to force one sooner. If a rebuild itself fails, a table that still has data from an earlier build keeps showing it, with a banner reading “Showing data from … Updates have failed since …” and a Not updating marker on the Feature’s table list; a table with no earlier data shows Build failed (with the expandable error) instead. See When a table stops updating. If a table it reads was deleted for good, or is in the trash, its page says so with its own banner, and rebuilding won’t clear it: restore the input, or edit the recipe and its inputs together (see Builds). While a rebuild runs, the page shows “Building table…”. See Fix data issues.

Version history

1. Open the table page’s Activity section to see the committed versions.
2. Click the restore action on a version — the Restore version modal asks “Why are you restoring this version?”.
3. Confirm. On review-gated tables the version comes back as a new draft for review; restoring is blocked while you already hold a draft (“A draft already exists. Discard it first to restore.”).