> ## Documentation Index
> Fetch the complete documentation index at: https://docs.textql.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Data Apps
> Prompt Ana in chat and get a working, interactive application back
TextQL **Data Apps** let you describe an application in plain English and get a real, working app back — built by Ana, connected to your data, and ready to share.
## 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](/core/ontology/overview)'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"
Ana builds the app, wires up the data it needs, and shows you a live preview you can immediately click around in.
## 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](/core/how-it-works/dashboards#data-sources) that power Dashboards:
| Type | Description |
| ------------- | ---------------------------------------------------------------------------------------- |
| `sql_query` | A SQL statement run against one of your connected database connectors |
| `library_tql` | A reference to an existing `.tql` file from your Ontology Library |
| `file` | An uploaded dataset file (CSV, Excel, etc.) |
| `python_code` | Python that produces the source's data, computed once and baked in when the app is saved |
### 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 `sql` function, anything with branching logic runs as a `python` function, and it's reachable from `tql` functions as well
## Lifecycle
1. **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.
2. **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.
3. **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](/core/how-it-works/data-apps/ana-functions).
4. **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.
5. **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_sql` data 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](/core/how-it-works/data-apps/ana-functions#in-the-front-end) — 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](/core/how-it-works/dashboards) (Streamlit-based) instead of the default Data App
If a prompt doesn't mention one of these, Ana will make a reasonable default choice — but calling it out explicitly is the difference between "close to what I wanted" and "exactly what I wanted" on the first try.
## 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.
| Category | Example | Description |
| ------------------ | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
| Project management | Ticketing tool | Linear/Jira-style board showing open issues, cycle burndown, and DRI workload (connected to GitHub / bug reports) |
| HR / Ops | Centralized People & Spend Hub | One place showing headcount, roles, org structure, and corporate spend by department/vendor (connected to Ramp) |
| Talent | Hiring Portal | Pipeline of candidates by stage, resume/LinkedIn links, and interview notes |
| Sales | Deal Pipeline & Forecast Tool | Live opportunity board with stage probabilities, forecast rollups, and stale-deal alerts |
| Finance | Revenue and usage dashboard | MRR, invoice status, run-rate by account |
| Marketing | Campaign analytics | Email campaign performance, signup funnels, lead source attribution |
| Operations | CSV Import & Validation Tool | Map any CSV's columns to your own fields, validate every row inline against custom rules, and export a clean CSV or PDF |
## Enabling Data Apps
Data Apps must be enabled for your workspace before you can create one.
1. Navigate to **Settings → Capabilities**
2. Toggle **Enable Data Apps** to on
Enabling Data Apps doesn't take anything away from Dashboards — dashboards you've already built stay fully usable. Any user with admin permissions in your organization can enable this. If you do not see the toggle, contact your organization administrator or reach out to [support@textql.com](mailto:support@textql.com).
## 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
## Embedding Data Apps Externally
A Data App can be embedded directly in your own product — not just shared inside TextQL — and supports per-user Row-Level Security (RLS), so each embedded viewer sees only the rows they're entitled to. See [Embedding Data Apps](/core/guides/embedding-data-apps) for prerequisites, setup, and the full walkthrough.
## Getting Support
If you have questions about Data Apps or run into issues, reach out to [support@textql.com](mailto:support@textql.com) or visit the [customer support page](/core/get-started/customer-support).