Build an app

An app is a small interactive application Ronja writes for you — filters, forms, charts, KPI tiles — that queries your tables. An app reads its smaller tables from a copy taken when you open it, so if data changes while the app is open, reload the page to see it. Like most resources, there is no app editor and no “new app” button anywhere: you describe what you want in a Build-mode conversation and iterate there.

If what you want is something to click inside the conversation you are already having — one view, for yourself, gone when the chat is — ask for an inline app instead. It needs no Build mode, no feature and no publishing, and it runs with each reader’s own access rather than one shared set of powers.

You never have to ask for an app to look right. An app Ronja builds is styled in Ronja’s own design system from the first compile — the same type, spacing, buttons and chart colors as the rest of the product — so a half-built app looks unfinished rather than broken. Ask for your organization’s brand and she applies it on top of that. When the design system itself changes, a styled app takes the new look the next time it is edited, and you see it in the preview before you publish.

An app that was never styled with Ronja’s design system keeps exactly the look it has, and nothing changes on its own. If an older app of yours renders as plain unstyled text, ask Ronja in a Build-mode conversation to bring it up to date: she changes a setting on the app rather than rewriting it, and on a shared app the change goes through the usual review. Ronja only suggests the change for an app she can see is already using the product’s design system; for the few that were hand-styled, bringing them up to date would change how they look, so she says nothing and leaves them as they are.

Ask for the app

Click New Exploration.
Select Build on the start screen.
Describe the app — the product’s own suggestion: “Build an interactive app to explore our sales pipeline”.
Approve the Create app card if Ronja pauses for your confirmation (it always does when the target feature is shared).
Watch the side panel: a build-progress page walks through “Set up the canvas” → “Sketch the layout” → “Polish & compile” → “Ready to explore”. As soon as the app compiles cleanly, it renders right in the panel — as a preview, for you. Ronja checks her own work before she hands it over: she opens the app herself, looks at what it actually renders, and reads the queries it ran — so an app that builds cleanly but comes up blank gets caught and fixed before you’re told it’s ready.
Publish it. Ronja asks to Publish 1 app; click Approve. Until you do, the app is an unpublished draft that only you can see.
Read what she says next. Publishing now tells you who can open the app and what they can do in it — for example, Everyone in your organization can open “NCR register” (its feature “Quality”). Anyone who opens it can read tables “ncr”, “ncr_events” and WRITE via secret “ncr_db write role”. If that is not the audience you meant, change the app’s feature before people start using it.

When Ronja publishes the app in chat, or when you publish it with the CLI, you get one sentence naming the audience and the powers:

In a private feature: Only you (and admins) can open “Sales pipeline” — its feature “Scratch” is private. Share the feature to give it an audience. An app in a feature you have never shared has an audience of one — you, plus your Admins, who can read everything in the organization — however finished it looks.
In My Private Feature: Only you (and admins) can open “Sales pipeline” — its feature “My Private Feature” is a personal home, which can never be shared. Move the app into a feature of its own and share that to give it an audience. This is the common case rather than an edge one: every Make my own copy lands there, and so does anything you build without picking a feature. The way out is the move, not a promotion.
In a shared feature: Everyone in your organization can open “NCR register” (its feature “Quality”). Anyone who opens it can read tables “ncr”, “ncr_events” and WRITE via secret “ncr_db write role”. Every viewer gets the same powers — the app cannot tell viewers apart.

That last part is the one to read twice. An app has one set of powers, shared by everyone who can open it. If it can write to a database, every viewer can write to that database — the app cannot give one person a read-only view and another the ability to change things. When you need that distinction, keep the writing in a workflow or a Saved Agent that runs as a named person, and let the app read. The one exception is a link the app hands the reader to open in a new tab — to a file, or to a page in Ronja such as a metric’s (below): that link carries the reader’s own access, so a colleague who cannot open the file on the Files page, or the page itself, cannot open it from the app either — the app tells them so, or shows whatever it falls back to.

If your change needs an Admin’s approval first, the sentence says so in the future tense — Once approved, everyone in your organization will be able to open… — because nothing is live yet.

Exploration side panel showing the app build-progress checklist while Ronja writes files The side panel while Ronja is still drafting the app.

Expand the Create app card and it lists the Tables, Secrets and Capabilities the app starts with. It’s a summary, not the full inventory — an app can also start out wired to metrics, workflows, Saved Agents or Codexes, which get no row of their own; ask Ronja to list the app’s full starting reach in chat if you want to see all of it.

That list isn’t fixed either: as Ronja writes the app, it picks up whatever its code actually reads — add a query against a table and the app gains that table. What it can never do is grow past you. Nothing is ever added to an app that you couldn’t reach yourself — every table, secret and metric is checked against your own access at the moment it’s added, and refused if it’s beyond you. What you reach depends on your role: for most members that is what your access groups and features reach; an Admin can wire in any live table or secret in the organization by id, including one in a feature no access group is attached to.

It works the other way round for the people who open it: a published app shows its numbers to everyone who can reach its feature, whether or not they could open those tables directly. Pick the app’s feature with that in mind.

Ask Ronja for a table that sorts, filters, pages and exports: a search box across every column, a filter under each column, a totals row, a row count under the table, Rows per page with Previous / Next, and Export CSV, which saves the filtered rows’ visible columns (a column of buttons is left out). The row count follows the filters and the search: a table narrowed to ten of its sixty rows reads 10 rows (filtered from 60). A filter that lists a column’s values shows how many of the rows still showing have each one, and (blank) picks the rows with no value. While a filter or the search is on, Clear filters resets them all at once. In the totals row an average is marked Avg and a count Count, and an average of whole numbers shows two decimals. A row you can click to open also opens from the keyboard: Tab to it, then press Enter or Space.

A long text value is cut short with … so the other columns stay in view. Hover over it to read all of it, or click it to show that row’s text in full; click again to shorten it. Ask Ronja to wrap a column if its text should always show in full.

An app that was published earlier keeps the table it has until its next change is published.

On a chart with more than one series, clicking a legend entry hides that series and the chart rescales to what is still shown; the series stays hidden when the data refreshes.

Iterate

Click the crosshair icon in the panel header (“Click anything in the app to ask Ronja about it”), then click any element and tell Ronja what to change.
Toggle App / Code to read the app’s source (read-only).
Come back any time: every app has a Work on it button that opens a fresh exploration seeded with it.

If the app saves changes, ask for the outcome to be visible. A save that matches nothing — someone else closed the record a minute ago, or the row has already moved on — is not an error, and an app that simply re-reads the data afterwards looks like it saved. Ronja can tell how many rows a save actually changed, so ask for it: “If a save doesn’t change anything, tell the person instead of just refreshing.”

A form Ronja builds also handles two cases on its own. When a save may already have gone through — the connection dropped just after it was sent, say — the form tells the person to check the list, and won’t save again until they change a value. And when a managed database refuses a value, the message can sit on the field to fix: ask Ronja to point each of the database’s rules at its field.

An app built before Ronja changed how backslashes are read may show a Legacy SQL escapes chip: its queries still read backslashes the older way. The next change Ronja makes to its code moves it to the current behaviour, and the chip clears when that change is published. See how backslashes in SQL are read.

Show a governed metric

An app can display your organization’s governed metrics — so a KPI app shows the official number instead of a hand-rolled copy of the calculation.

Ask Ronja to build (or add to) the app using a specific metric, e.g. “Add a tile showing our Average Order Value metric, broken down by country.”
Ronja wires the app to that metric and grants it access — you don’t manage an allow-list by hand.
The app always reads the live, verified definition: change the metric once and every app that uses it updates.

An app can only show metrics you can already reach — for most members that is what your access groups and features reach; an Admin can wire in any metric in the organization by id, including one in a feature no access group is attached to.

To let a reader click through from a tile to the metric’s own page, see Link to a page in Ronja.

A breakdown can be clipped like any other read: ask for a metric broken down by more categories than the app loads and you get the first of them, not all of them. The app says so — Metric breakdown was truncated — some categories are missing — which means a chart or table is short a few rows rather than showing wrong ones. Tell Ronja if the breakdown needs to be complete.

Link to a page in Ronja

An app can link to a page elsewhere in Ronja, so a reader can click through from what the app shows to where it lives — from a KPI tile to its metric, or from a row of a list to its table. Ask for it, e.g. “Link each tile to its metric.” The same works for a table, a workflow, a note, another app, a Saved Agent or a managed database.

It opens in a new tab, and the reader signs in to Ronja as usual.
It is worked out for whoever is looking at the app. Ronja only hands a link to people who can open that page themselves, so a colleague who can’t open the metric never gets a link to it.
There is no Admin exception. An Admin gets links only to what their own access groups and features reach, not to everything they can open as an Admin, so an Admin looking at a colleague’s private app may see no link where the colleague does.
A link gives the app nothing. Linking to a metric doesn’t give the app its numbers; only showing it does.

An app linking many hundreds of different pages at once can reach a rate limit — see Limits and retention.

Add a chat panel

An app can carry a chat panel for one of your Saved Agents, so the people using it can ask a follow-up question in their own words instead of coming back to a conversation with Ronja. The Saved Agent answers using exactly what it was set up to reach — the same tables, notes and knowledge bases it uses anywhere else.

Ask Ronja to add it, naming the Saved Agent: “Add a chat panel to this app so people can ask the Pipeline Analyst about the numbers.”
Ronja wires the app to that Saved Agent and grants it access, the same way it does for a metric — you don’t manage an allow-list by hand.
Tell Ronja what the panel should say before anyone types: a one-line description of what the Saved Agent is for, and a couple of example questions, both of which appear in the empty panel. It is worth doing — a blank box gets blank questions.

Everyone who can open the app can use the panel, and each person gets their own conversation — one person using the app never sees another’s, and the Saved Agent has no memory of theirs. These conversations are not private from your admins: an admin can reach one, and even add to it, through the Saved Agent’s own history. What they cannot do is open it inside Ronja — a panel conversation appears in no list and on no page in the product, so treat it as out of sight rather than as confidential. That reach has an end: a panel conversation is kept 1 year after its last message, and is then deleted along with its transcript (see Limits and retention).

The Saved Agent answers, and it can use the tools it was already approved for. What it cannot do is stop and ask a person for permission: there is nobody to approve a step inside an app the way you would in an exploration, so if the Saved Agent needs a decision it cannot make itself, it says so in its reply and stops there rather than doing it.

Two kinds of Saved Agent can’t be used in a panel at all, and Ronja tells you which when you try. One is a Saved Agent set up to ask people questions — that step has nobody to ask here. The other is a Saved Agent approved to use every tool: some older agents carry a single blanket approval instead of a named list, and a panel has no way to hold back a Saved Agent that is already approved for everything. The fix in both cases is to point the panel at a different Saved Agent, or to replace the blanket approval with the specific tools that Saved Agent needs.

Chat costs credits like any other agent work, and it stops when the organization is out of them — the panel says so plainly rather than failing silently. See Govern AI spend.

Sharing is feature-based: once published, an app is visible to exactly the people who can reach its feature — there is no per-app access list. Before it is published nobody but you can see it, whatever its feature, so publish it first and then decide who reaches the feature.

Open the app on its own page and click Share… (shown while the parent feature is still private).
Promote the parent feature, or move the app into a shared feature. Admin approval applies where the governance flow requires it — see Share and promote. One exception: if the app sits in My Private Feature — where every Make my own copy lands — the modal offers the move alone, because that feature can never be shared. Move the app into a feature of its own and share that.

Make your own copy

The draft-and-review round above is the right shape when you want to change the App for everybody. When you only want it for yourself — a version with your filters, your columns, your extra panel — take your own copy instead. You do not need to be an Admin, and nobody has to review it. You do need Build mode access, since that is where you will edit the copy.

Open the App on its own page and click Make my own.
Name your copy, or leave the box blank — a blank name gives you the original’s name with a short suffix, so the two are never confused.
Click Make my own. The copy opens on its own page, in My Private Feature — visible to you and to your Admins, and to nobody else. That feature can never be shared, so to give the copy an audience later, create a feature, move the copy into it, and share that.

Your copy is independent from the moment it is made. Editing it never touches the original, and later changes to the original never reach your copy — there is no sync, no link back, and no “update from original” button. If you want the original’s later improvements, make a fresh copy.

Two things grey it out, and both name themselves — point at or tab to the button and it says which.

Something the App uses isn’t available to you — a Table whose feature you can’t reach, a Secret, a Metric, a Codex, a Saved Agent, a Workflow. The sentence names them: tables and the rest by name, and Secrets counted rather than named (“1 secret”). It says “may have been deleted, or you may not have access” because both are true from where you stand and Ronja won’t tell you which — so if an Admin says you already have access to everything named, the thing has been deleted and the App needs fixing rather than your account. Otherwise it is an access request: ask for access to the things it names, or ask them to share the App’s feature with you.

Build mode is off for your account. Editing an App happens in a Build-mode conversation, so a copy you can’t edit would be no use. Ask an Admin for Build mode access.

User Read-Only members do not see the button at all: making a copy is a change to your organization’s contents, and that role makes none. That one an Admin can fix outright: ask them to change your role to User. Nor does it appear on a draft, a proposal, or an older version of an App — only a published App can be copied, and that is not something anyone can grant.

Find it on the Apps page

Apps in the sidebar — “Tools built on your data. Open one and start working.” — lists every app you can reach as a card showing its icon, name, description, the feature it belongs to, and when it was last updated.

The icon is one Ronja draws when she builds the app: a small picture of what the app is about. To change it, or to give an older app one, ask her in chat — “give this app an icon of a forklift”. Like any change to a published app, the new icon shows on the card once that change is published. The same icon marks the app’s card on Home. An app without an icon shows a plain window icon.

Open it. Hover a card and click Open.
Keep it close. Click the star on a card to favorite it; favorites gather in a Pinned section at the top of the page (and in the sidebar’s Favorites).
Find your unpublished work. Your own drafts sit in a Drafts section under Pinned, so a new app is never buried. (A draft you have starred stays in Pinned — each app appears once.)
Narrow the list. Switch between All, Favorites, Shared, and Mine, then filter by owner or by status — Any status, Published, Draft, or Archived.
Find one fast. Type into Search apps, or change the sort: Last updated, Oldest first, Name A–Z, Name Z–A.

Open it standalone

Open the app from the Apps page. Every app has a page of its own, with a stable link you can drop into a channel or a document.
Click Fullscreen for a chrome-free view, useful for screen-sharing or projection. Exit with the corner Exit fullscreen pill. In fullscreen, the browser tab shows the app’s own icon when it has one (Chrome does; some other browsers keep the Ronja icon), so it is easy to find among your other tabs.

Standalone app viewer with the feature chip, Share, Make my own, Details, and Fullscreen header actions The standalone viewer.

If an app hits a runtime error, it shows “Something went wrong in this app” — in an exploration you can click Ask Ronja to fix, which hands the error straight back to the chat.

When a query returns more rows than the app loads, the app says so — wherever you have it open, not only here on its own page. Usually that is a notice across the top: Showing the first N rows of a larger result — totals computed from this data may be incomplete. So a total on the screen may be counting fewer rows than exist. Dismiss it with the × once you have read it, and tell Ronja if a number on the page needs to cover everything. An app that already states it in place — a list headed with its own “showing the first N” line — shows that line instead, and no notice across the top. Where a table’s row count says loaded rows, as in 1–25 of 5,000 loaded rows, it is counting the rows the app read, not every row that exists.

Link to a view inside the app

A bigger app has more than one view — an overview, a list, a detail page. As you move around inside it, the address in your browser updates to match, so the link you are looking at always points at the view you are actually on.

Share the exact view. Copy the address while you are on it and paste it into a message: whoever opens it lands on that view rather than the app’s front page. They still need access to the app’s feature to see anything.
Bookmark it. A bookmark saved from inside an app reopens on the same view.
Use Back and Forward. Your browser’s Back and Forward buttons step through the views you visited inside the app, one press at a time.

Ronja keeps your place while she works too: when she rebuilds an app you have open on its own page, it reloads on the view you were on.

A single-screen app has just the one view, and its address never changes.

To link from the app to a page elsewhere in Ronja — a metric, a table — see Link to a page in Ronja.

Look behind the app

Everything about an app — what it reads, who can open it, its source, its history — lives on its Details page, so the app itself stays uncluttered. Get there from Details in the app’s header, or the ⓘ button on its card on the Apps page. Open app in the header takes you back to the app at any time.

Overview — a plain-language summary of what the app shows and lets you do, its owner, feature, visibility, and when it was last published; Dependencies, listing every table, metric, workflow, agent, secret, and knowledge base it uses, with View dependency graph for the full picture; and Version history (see Versions, drafts, and approvals).
Access — who can open the app, then two lists: Data it can read and What it can call. Worth reading before you share an app: anyone who can open it reads its tables through it, whether or not they can read those tables directly. These lists are maintained by Ronja as it builds, and enforced on every request the app makes — they aren’t editable by hand.
Source — the app’s files, read-only. An app is usually several files; pick one from the list on the left, or on a narrow screen such as a phone, from the menu above the code. The selector at the top chooses which copy you’re reading: Live (what everyone else sees), Your draft if you have unpublished changes, or any past version.
Activity — who created, changed, and published the app, and when.
Settings — the app’s name, description, reporting timezone and currency, plus deleting it. Editing these is available to an admin, to the owner of the Feature the app sits in, or — on a shared app — to its author, whose changes become a draft an admin reviews. Deleting a shared app is Admin only. On a shared app, saving creates a draft for an admin to review rather than changing it live. The reporting timezone applies to the queries the app runs itself; a metric it displays keeps its own calendar, so the two can differ on purpose. When a timezone change takes effect, anyone who has the app open sees it reload. Amounts follow the organization’s reporting currency, set once on the Organization rules page (see organization settings), so every app agrees without anyone configuring it. Use Amounts in this app are in only when this app’s data genuinely is in a different currency — a subsidiary’s ledger, a supplier’s price list. Numbers keep the organization’s formatting and only the currency changes, so a Swedish organization reading a dollar app sees 2 602,50 $. It states what the data already is and converts nothing. If no currency is set anywhere, Ronja asks which one to use before building anything that handles money.