Overview
A Data App is a small, self-contained application: a multi-file front end written in React and JavaScript that Ana writes and assembles, backed by data sources and server-side compute functions you describe in chat. Unlike a one-off chart or a chat response, a Data App is a persistent artifact with its own URL — you can return to it, share it, iterate on it, and roll it back to an earlier version. A Data App lives as a file in your Ontology’s git-backed file tree, alongside the data, definitions, and workflows it depends on — the same versioned repo covered in Ontology, not a separate system. That’s what makes an app discoverable: anyone (or Ana) can see what it relies on without reconstructing that context from scratch, and changes to it are versioned the same way as any other ontology change. The core loop is simple: prompt it in chat, and you have your app.- “Build me a data app where I can search customers and see their order history”
- “Build me a data app where my team can log which leads they’ve followed up on”
- “Build me a data app where people can claim open shifts”
What’s Inside a Data App
A Data App is made of four parts. Ana creates and wires up all four when it builds the app — you don’t configure these directly, but knowing what they are makes it easier to describe what you want.Front End
The UI Ana writes: an entry document, JavaScript modules using React (no build step required), stylesheets, and any images, icons, or static copy the app needs.Data Sources
Named, reusable connections the app reads from — the same kind of Data Sources that power Dashboards:Compute Functions
Server-side logic that runs live, at view time, instead of being pre-baked into the app. This is what makes write-back, live filters, and anything that needs fresh data or a persisted change possible. Compute functions can be written as SQL, Python, or TQL (ontology queries), depending on what the app needs to do.App Database
Every Data App has its own private, persistent database, powered by DuckDB — embedded in the app, with nothing to configure in your org:- No setup — Ana provisions it automatically as part of the build; no connector, no credentials, nothing running on your infrastructure
- Scoped to the app — separate from your warehouse, shared live by every viewer, persists across edits and sandbox recycles
- Accessed only via compute functions — reads and writes go through declared compute functions: a single statement runs as a
sqlfunction, anything with branching logic runs as apythonfunction, and it’s reachable fromtqlfunctions as well
Lifecycle
- Create — Prompt Ana in a chat. Ana writes the app’s code, connects any data sources and compute functions it needs, builds it, and takes a screenshot to self-check before showing it to you.
- Iterate — Keep talking to Ana to change what the app does or looks like (“add a filter for region,” “make the submit button save to the orders table”). Ana edits the specific files and lines that need to change rather than rewriting the whole app.
- Edit directly (optional) — If you or someone on your team wants to touch the code by hand instead of going through Ana, you can. The app’s code talks to the platform through a small built-in SDK, documented in The ana.* Functions.
- Share — There’s no separate publish or hosting step. A Data App is shared the same way as a Thread or a Playbook — access is governed by the same role-based permissions as everything else in TextQL. Share it with specific people, your whole team, or keep it personal.
- Version history — Every save is a checkpoint you can return to. If a change goes wrong, restore a previous version.
Best Practices
A Data App is only as good as the prompt that built it. A few habits make a real difference:- Point Ana at your ontology first. If the metrics or entities the app needs are already modeled — “active customer,” “churned deal,” “on-time shipment” — say so and Ana builds against those governed definitions (an
ontology_sqldata source) instead of writing new SQL from scratch. Same logic, same numbers as the rest of your ontology, not a second definition to drift out of sync. - Name the data source, not just the outcome. “Connect this to our Postgres orders table” gets a more reliable app than “show me my orders” — Ana still has to guess where the data lives in the second case.
- Say whether the app needs to remember anything. If someone will submit a form, resolve an item, or update a status, say so explicitly (“let people mark a row as done”) — that’s the cue Ana needs to wire up a real write, not just a read.
- Describe the interaction, not just the layout. “A board where people drag a card between columns” tells Ana what to build; “make it look like Trello” only tells it what to imitate visually.
- Iterate in small asks. Get the core view working first, then layer on filters, actions, and polish one at a time — Ana edits the specific pieces that need to change rather than rebuilding the whole app, so small asks stay fast and precise.
- Say if more than one person will use it at once. An app meant for a team behaves differently from one meant for just you — mention it up front so Ana adds the shared-awareness pieces (who’s viewing, who did what) instead of building a single-player view.
Prompt Language That Invokes Specific Features
Some capabilities only show up if you ask for them by name:- “connect this to [connector/table]” → A real, named data source wired into the app
- “let people save / submit / mark as done / resolve / update” → Write-back — the phrase that tells Ana the app needs a write-enabled database connector, not just a read. Without one, there’s nowhere for a save action to persist to.
- “show who’s viewing this” / “keep a log of who did what” → Multi-user awareness — presence and an activity feed
- “let me bookmark this exact view / filter / record” → Deep links — the app’s URL updates as someone navigates
- “link from here to my [other app]” → Cross-app navigation — a click sends the viewer into another Data App, optionally landing on a specific record inside it. Available to signed-in viewers on the app’s own page; Ana hides the link where it can’t work, such as public share links and embeds
- “add a [bar/line/donut/area] chart of X” → A specific chart type from the built-in toolkit, instead of a generic visual
- “use [a named library]” → An external JavaScript library pulled in for something outside the built-in toolkit (a specialized chart type, a date picker, etc.)
- “make it feel more alive” / “animate in as I scroll” / “count up to the total” → Tasteful motion — hover states, scroll-reveal, count-up numbers
- “build this as a dashboard” / “make me a Streamlit dashboard” → A Dashboard (Streamlit-based) instead of the default Data App
Example Categories
Data Apps work well anywhere a small internal tool would help — a lot of what teams pay for in point SaaS products can be prompted directly instead.Enabling Data Apps
Data Apps must be enabled for your workspace before you can create one.- Navigate to Settings → Capabilities
- Toggle Enable Data Apps to on
Sharing and Permissions
Data Apps follow your organization’s role-based access control:- The creator can share an app with specific people as an editor (can edit) or viewer (can use, not edit)
- Apps can be shared with your whole team or kept personal
- Admins can view and manage apps across the organization