An app your team actually uses

There’s a question your team asks every week. “What does the pipeline look like?” “Where are we against target?” Someone answers it — by re-running the same analysis, screenshotting the same chart, pasting it into the same channel. The answer is good. The process is a tax.

An exploration answers a question once. A data app answers it every time anyone opens it — an interactive page with live numbers, filters, and drill-downs, built by Ronja from a conversation and shared with the team like any other resource. Here’s how a repeated question becomes one.

Ask for an app

In an exploration, switch to Build mode and describe what you want. The Data Apps page itself suggests the shape of the ask: “Build an interactive app to explore our sales pipeline.”

Before anything exists, you stay in control. When the app targets a shared feature, Ronja pauses on an approval card — Create data app — that spells out the app’s name, its feature, and, crucially, which tables and capabilities it will be allowed to touch. A data app can only query the tables on its allowlist; approving the card is approving its reach, not just its existence. (There is no “new data app” button anywhere — data apps are asked for, and whenever one targets a shared feature, this contract is explicit.)

Watch it take shape

The app builds in a side panel right next to the chat. First you see the drawing board — a four-step build checklist from “Set up the canvas” through “Sketch the layout” and “Polish & validate” to “Ready to explore” — and the checklist advances as the first files land. When validation passes (Validation passed — the bundle compiles cleanly), the panel reloads into the real, running app.

The app takes shape beside the conversation — what you preview is exactly what your team will open.

Iterating is conversational, and unusually direct:

• Point at things. The panel’s element picker lets you click any part of the running app — a chart, a number, a button — and ask Ronja about exactly that. “Make this a weekly view.” “This total looks wrong.”
• Read the code if you like. An App / Code toggle shows every source file, read-only. Nothing is hidden.
• Errors route back to the builder. If the app hits a runtime error, the overlay offers Ask Ronja to fix — the error goes straight into the chat and she takes a look.

And because data apps are real applications, not static views, they can do things: filters and date pickers, KPI tiles and charts — and even forms, where submitting dispatches a workflow. That’s the only way an app writes data back, which means every write goes through a governed, inspectable job rather than a hidden side door.

Make it everyone’s

Here’s the part that turns a personal toy into a team asset. A data app’s audience is its feature’s audience — there are no per-app permission lists to maintain. On the app’s own page, click Share… and choose: promote the whole feature to your workspace or organization, or move just this app into an already-shared feature. Either way the change rides the normal sharing flow, and an admin approves it.

If you’re not an admin, the system stages your work instead of blocking it:

• A brand-new app aimed at a shared feature becomes a proposal — the chat card reads awaiting admin approval, an admin reviews the app (including its table allowlist and rationale) and approves or rejects it.
• Edits to an already-shared, live app fork into your own private draft. Everyone else keeps seeing the working version while you iterate; when you’re ready, Submit for review hands the diff to an admin, who can open a preview of your draft before approving. Every committed change is kept as a version that can be restored later.

The result is something hand-maintained reporting never had: the team’s app can evolve weekly without anyone being able to quietly break it. See Propose and review changes for the full lifecycle.

Where the team meets it

Once shared, the app is simply there:

• Data Apps in the sidebar lists every app you can reach, with search and filters; pin a favorite and it gets its own sidebar entry.
• Every app has a standalone page of its own — a stable link you can drop into any channel or doc.
• Fullscreen opens the app full-bleed, without any Ronja chrome — built for the Monday meeting screen-share or a wall display.
• Work on it, on every list row, spins up a fresh exploration pre-loaded with the app — so the next iteration starts exactly where the last one ended, for anyone with access.

Admins even get an honest answer to “is anyone using this?” — the activity page’s data-app usage table shows opens, viewers, last opened, and query counts per app.

Why this sticks

Repeated questions usually die in one of two ways: a BI license nobody renews, or a heroic spreadsheet nobody dares touch. A data app avoids both because it’s made of the platform itself. It’s sandboxed by construction — credentials never reach the browser, and writes only happen through workflows. It’s governed like everything else — proposals, drafts, reviews, versions. And it’s maintained the way it was built: by asking.

The question your team asks every week deserves better than a weekly ritual. Ask Ronja to build the app — then never answer that question by hand again.