Build an app

Who can do this

Creating and editing apps requires Build mode access (enabled per account by an administrator). Anyone who can reach an app’s feature can open and use it. Publishing changes to a shared app requires an Admin.

An app is a small interactive application Ronja writes for you — filters, forms, charts, KPI tiles — that queries your tables live. 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.

Ask for the app

1. Click New Exploration.
2. Select Build on the start screen.
3. Describe the app — the product’s own suggestion: “Build an interactive app to explore our sales pipeline”.
4. Approve the Create app card if Ronja pauses for your confirmation (it always does when the target feature is shared).
5. 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.
6. Publish it. Ronja asks to Publish 1 app; click Approve. Until you do, the app is an unpublished draft that only you can see.

Caution

A new app is not live just because it renders in the panel. What you are looking at is your own preview. Until it is published the app appears on the Apps page only for you, carrying a Draft badge on its card — and, once you have published apps to separate it from, in a Drafts section above them. Nobody else can see it at all. If Ronja does not offer to publish, ask her to: say “publish the app”. The app keeps the same address through publishing, so a link you copied while building keeps working.

The side panel while Ronja is still drafting the app.

Tip

Describe the app you want in detail, and check the Plan Ronja writes before she builds. Agreeing on the scope first gets you the app you actually wanted and saves credits versus rebuilding it after the fact.

Caution

If you’re not an admin and the app targets a shared feature, it’s created as a proposal — an Admin approves it before it goes live to the access group. See Propose and review changes.

What the app is allowed to read

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.

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.

Tip

Apps can reference your teammates. Ask for a searchable assignee picker, an approval router, or a “who owns this” field, and Ronja builds it from your organization’s member list — the same people already in your access group, with their name, email, and role. Nothing outside your organization is ever visible.

Iterate

1. 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.
2. Toggle App / Code to read the app’s source (read-only).
3. Come back any time: every app has a Work on it button that opens a fresh exploration seeded with it.

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.

1. 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.”
2. Ronja wires the app to that metric and grants it access — you don’t manage an allow-list by hand.
3. 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 in your own access groups and features.

Share it

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.

1. Open the app on its own page and click Share… (shown while the parent feature is still private).
2. 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.

Caution

Once an app is shared, your edits fork a private draft — the live app keeps serving everyone else until an Admin publishes. Click Submit for review on the draft banner; the pill flips to Review requested while an Admin reviews the change. (If you’re the drafting admin, the banner shows Commit instead and you publish directly.)

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.

• 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

1. 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.
2. Click Fullscreen for a chrome-free view, useful for screen-sharing or projection. Exit with the corner Exit fullscreen pill.

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.

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.

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; Depends on, 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. 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, and reporting timezone, plus deleting it. Available if you’re an admin or you created the app. 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.

Live and your draft are different things

On the Source tab, Live is what your colleagues see. If you have unpublished changes, Your draft is a private copy only you can read — publish it before expecting anyone else to see it.