Data Apps

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’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 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 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.
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. There is no draft state: every save is live for everyone the app is shared with.
5. Refresh: Snapshot data sources are re-fetched when anyone clicks Refresh All Data in the app, or automatically on a schedule that a user with edit access sets from the app’s Refresh menu (times are stored in UTC). A refresh updates the app in place for every viewer, so there is nothing to publish afterward. The Refresh menu shows when the data was last refreshed, and the app’s creator is notified in-app and by email if a scheduled refresh fails.
6. 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 — 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

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.

​

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

​

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

​

Row-level security

When the people you share an app with are entitled to different rows, enforce it in governed .tql files that read the viewer’s identity. Each live query then renders as the person viewing, and that data never enters the app’s shared snapshot. See Row-Level Security for the pattern and a worked example.

​

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 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 or visit the customer support page.