Tables
Tables hold the data everything else in Ronja is built on. Every table lives in a feature (with one scratch-pad exception — see Session tables below), has a kind that says where its data comes from, a build lifecycle that keeps it fresh, lineage that connects it to the rest of your data estate, and a trust state that says whether the organization stands behind it.
The four kinds
Section titled “The four kinds”Each table wears a kind chip, and the product explains each one in a sentence:
| Kind | What it means (product copy) |
|---|---|
| Foundation | “Cleans and standardizes raw source data into a reliable base layer.” |
| Integration | “Synced from an external connection — its shape mirrors the upstream system.” (Tables updated by uploading files directly also display as Integration.) |
| Derived | “Built from other tables as inputs, typically via SQL or Python.” |
| Dynamic | “Written to directly by agents as they run.” |
The kind decides what you can do on the table page. Derived tables expose their code — a third tab alongside Result and Catalog — because they’re defined by a query over inputs. Foundation, Integration, and Dynamic tables hide per-table build controls.
Builds
Section titled “Builds”A table’s contents are produced by a build. On the table page you’ll see its state at a glance: a status dot, “Building table…” while a build runs, and banners when something needs attention — “Build failed” with an expandable error, or “Out of sync — showing data from last successful build” when the data on screen predates a change. Stale tables show a rebuild affordance; rebuilding is an Admin action. Every one of these banners also carries an Investigate with Ronja button, which opens a Build-mode exploration already diagnosing that table’s failure — see Fix data issues.
Ronja sizes each build automatically — you’ll see a small read-only badge (Light, Batch, and up) and, for big tables she builds in several pieces at once, a Parallel badge. Nothing to configure; it’s just telling you how heavy the build was.
The reporting timezone
Section titled “The reporting timezone”Beside those badges, a Derived table shows the reporting timezone it is built on — for example Europe/Stockholm — when it has one. That’s the calendar Ronja groups by when the table rolls data up per day, week, or month, so an order placed at 23:30 lands on the day it belongs to locally rather than on the next day in UTC.
It matters most for month and quarter boundaries: the same query grouped on two different calendars puts invoices dated the 1st in different months. Fixing the calendar to the table means everyone reading it sees the same numbers, whatever timezone their own browser is in.
New tables take your organization’s timezone (set by an admin on the Approvals page in the admin area) and keep it from then on — changing the organization default later doesn’t quietly move the calendar of tables you’ve already built. If your organization hasn’t set one, new tables simply don’t declare a calendar and group by UTC, exactly as tables did before this existed. Tables built before your organization set a timezone are left alone too — nothing was quietly relabelled. Like the other build settings, it’s read-only on the table page. To change it, ask Ronja in chat: she stages the change as a draft, rebuilds it on the new calendar so you can check the result, and only then publishes it.
Because it’s fixed when the table is created, the organization default is worth setting before people start building — otherwise tables built earlier and later sit on different calendars. That matters when two tables are combined: if one groups by month on UTC and the other on Europe/Stockholm, rows near a month boundary line up against the wrong month, and nothing reports an error. If your organization changes its timezone, it’s worth asking Ronja to re-check the tables you already rely on.
If a table doesn’t group by day, week, or month at all, its calendar makes no difference to the numbers — so this is only worth thinking about for roll-ups.
Lineage
Section titled “Lineage”Tables don’t exist alone, and the table page shows their connections directly:
- Inputs — the tables a Derived table is built from. An input that lives in a feature you don’t have access to still appears, showing its name and the feature it belongs to, but it isn’t clickable — so you can see where the data comes from and who to ask.
- Dependents — the downstream tables built from this one.
- Producers — the workflows that write this table.
A “Show in architecture” action opens the table’s pipeline in the organization-wide architecture graph, and from a feature’s Inventory list, “View in graph” shows a resource’s cross-feature dependencies. Lineage is why Ronja’s answers are traceable: you can always walk from a number back to its sources.
A table’s page shows its own lineage; to see the whole picture — how this table connects to the workflows, notes, and apps around it, including links that cross into other features — open the Graph action on the feature it lives in.
When several tables have nearly the same name, the useful question is which one the organization actually stands behind. An Admin answers it from the Governance · admin only panel on the table page: Verify endorses the table’s definition and gives it a green Verified badge; Retire flags one as historical and pushes it down in search.
After that, Ronja watches the definition. If it changes — a Derived table’s calculation, or a Foundation, Integration, or Dynamic table’s source binding or column shape — the badge turns amber “Verified · review pending” until an admin Acknowledges the change. Extra rows alone never count, so a daily refresh leaves a verified table cleanly verified; a column being added, dropped, renamed, or changing type does.
An unvetted table carries no badge at all, so a badge on a table page always means something. In Search (⌘K), a verified table comes first and a retired one last among results that match your search equally well; when Ronja searches during a chat, verification shifts how relevant she judges a table to be, so it can change which one she reaches for. The full picture, including what applies to metrics, is on Verification.
Reading a table
Section titled “Reading a table”The Result tab previews the data — small tables render in full as a searchable grid; larger ones show a capped preview. The Catalog tab is the column-statistics view: Field, Kind, Rows, Missing, Cardinality, and Examples per column. The “Explore this table” button starts a fresh exploration anchored on the table — “Ask anything · build · transform”.
Changing a table safely
Section titled “Changing a table safely”Edits to tables go through per-user drafts: your changes live in a draft (one per person per table) until they’re committed, and edits to shared tables by non-admins wait for review before going live. Version history lets you restore an earlier committed version. The full lifecycle is covered in Versions, drafts, and approvals; the hands-on recipe is Create tables with Ronja.
Two special cases
Section titled “Two special cases”- Session tables — scratch tables that exist only inside one exploration. In the product’s words: “This is a scratch table that only exists in this session. It isn’t saved to a feature and can’t be opened elsewhere.”
- Data dictionary tables — a table can be marked as a data dictionary and linked to the tables it describes, powering column and table descriptions across the product. See Maintain the data dictionary.
For a compact comparison of the kinds — source, rebuild behavior, editability — see the table types reference.