Next Gen Data Apps

Next Gen Data Apps is the next generation of Classic Data Apps: the same idea (AI-native, always-up-to-date dashboards), now with on-canvas editing and stronger guarantees around what your viewers see. It turns an analysis into a live dashboard you can edit directly on the canvas. You still build with chat, and now you can also drag panels, edit their properties, and rearrange the layout in place, then publish when it’s ready. Every version is rebuilt through a checked pipeline, so a change that fails to render never reaches your viewers.

​

What’s new

• Handles more data. Dashboards can load much larger datasets, on the order of a million rows, in full. The heavy processing happens in the pipeline up front, so charts and filters stay fast even over large data.
• Complete version history. Every version is captured with a complete, reliable history. You can review exactly what changed before publishing, keep a clear split between your working draft and what viewers see, and restore any earlier version at any time.
• Render-checked publishing. Each version is rebuilt and render-checked before it goes live, so a broken change can’t reach your viewers. The app keeps serving the last good version.
• A structured app. Next Gen apps are a React app of separate, editable components, which is what makes on-canvas editing and reliable rebuilds possible.
• On-canvas editing. Shape the dashboard directly on the canvas (drag, edit, rearrange), with chat always there when you want it.
• More than your warehouse. Pipelines can pull data from MCP data sources (for example, a GitHub connection) alongside your warehouse, so a dashboard can combine warehouse metrics with data from your connected tools.
• On-demand steps. Some questions are too big to precompute — one customer’s orders among millions, or a live status that shouldn’t wait for the next refresh. Steps marked on-demand run when a viewer interacts with the app (for example, picking a value from a dropdown), instead of at refresh time. See On-demand steps.
• AI-generated insights. A pipeline can include an agent step that uses AI to produce content, such as a written insights summary of what the data shows, baked right into the app.

​

Data sources and pipeline steps

Every Data App is produced by a pipeline: a DAG of steps, so independent steps run in parallel and each one runs as soon as its inputs are ready. Next Gen Data Apps adds new data-step kinds beyond the warehouse-and-transform steps of Classic: Those datasets are rendered by a small React codebase (App.tsx plus one file per component under components/). You can browse both the data steps and the app code from the Source Code tab in the editor, or jump straight there with Source code in the app’s ⋯ menu. A run view organizes the pipeline into three groups: Steps (your data steps above), Gate (build, then render-check), and Publish. Because these steps are captured in the app itself, the whole dashboard is reproducible from its pipeline, and every rebuild is render-checked before it can be published (see Refreshing).

​

On-demand steps: live lookups at view time

By default, every pipeline step runs at refresh time and the app serves that snapshot. Any of the step kinds above except built-in tools can instead be marked on-demand: it runs at the moment a viewer interacts with the app, with values the viewer chose bound in as typed parameters. In the Source Code tab, on-demand steps carry a green ⚡ on-demand badge along with their parameters and cache duration. Use on-demand steps for two shapes of question:

• Needle in a haystack. A lookup across a space too big to precompute — one customer’s orders among 10M rows, one ticket’s detail among thousands. The dashboard’s rollups stay precomputed; the viewer’s pick queries live.
• Fresher than the refresh. A pane whose numbers should be minutes old, not as old as the last scheduled refresh — a live status or queue depth, with or without parameters.

The rest of the app is unchanged: on-demand results can join against the app’s precomputed datasets (for example, “this customer’s orders” laid over the daily rollup), and an agent step can run on demand too — generating an AI summary for exactly the record a viewer selected. To use it, just describe the interaction to Delphina — for example, “add a dropdown of customers, and when I pick one, look up their orders live”. Delphina marks the right steps on-demand and wires the app.

​

What viewers experience

• Selecting a value shows a Live lookup progress strip while the query runs; results typically land in a few seconds (agent steps take longer). Panes show a live · as of… badge telling viewers exactly when their numbers were produced.
• Results are cached per parameter value for a duration the app author chooses, so repeating a selection (by you or a colleague, where applicable) is instant.
• On-demand queries run under the viewer’s own data connections, not the owner’s — the opposite of refreshes. A viewer’s live lookups return exactly what their warehouse access allows, and results from credentialed lookups are private to the viewer who ran them. In workspaces where warehouse access is connected per user, a viewer who hasn’t connected theirs sees a prompt to do so instead of data.
• PDF exports print on-demand panes in their empty state for now — live lookups are per-viewer and aren’t captured in the exported document.

​

Creating a Data App

You can also start from scratch with + Create Data App on the Data Apps page and describe what you want.

​

Editing on the canvas

You can change the dashboard in place, right on the canvas. Editing is reserved for the app’s owner (see Ownership); non-owners get a read-only view of the same surfaces. In edit mode, hover or select a component to reveal its controls:

• Edit props: change a component’s settings (for example, a chart’s type, axes, or color)
• Drag to reorder: rearrange components within the layout
• Delete component: remove a panel
• Change this component: open a focused chat to have Delphina change that panel

​

Asking about the data

You can also chat about a component while simply viewing the app: select it and choose Ask about this data to ask questions about the data behind that panel. Delphina has the app’s pipeline and data in context, so it can answer questions about the output.

​

Draft and publish

This is the biggest change from Classic. Your edits save automatically to a draft. The editor banner reads “Editing — changes save automatically · draft”, so you can shape a dashboard fully before anyone else sees it. Nothing your viewers see changes until you publish.

• The Versions panel (right rail) marks your working draft as Latest and the live version as Published.
• Open the Diff tab to review what’s different from the published version.
• To make a version live, open it in the Versions panel and click Publish this version. You can also Restore an earlier version or jump Back to latest.

​

Refreshing

Refresh re-runs the app’s pipeline against the latest data (warehouse and any MCP sources). The analysis logic is frozen, so a refresh changes the data, not the design. Refreshes always run using the owner’s data connections, whoever triggers them (see Ownership). (On-demand steps are the one exception: they run outside the refresh, under the viewer’s own connections.)

• Manual: click Refresh now. The owner, the app’s editors, workspace Developers, and org admins can trigger it.
• Scheduled: set a frequency in the app’s settings (for example, daily).

Every refresh replays the pipeline through the same stages: your data Steps run, a Gate builds the app and render-checks it, then Publish releases it. If a refresh fails the render-check, the app keeps serving the last good version and surfaces the failure. Open the run from the failure banner to see what went wrong.

​

Versions

Next Gen Data Apps keeps a complete, reliable history of your app. Every version is captured automatically, so you can always see how a dashboard evolved and roll back with confidence.

• See the timeline. Open the Versions history to browse every version, with the current Published version and your Latest draft clearly marked. You can also jump there with Version history in the ⋯ menu.
• Review before you publish. Use the Diff tab to see exactly what’s different between your unreleased draft and the published version.
• Restore any version. Restoring makes that version your current draft, which you can review and then publish. Nothing is lost; restoring is itself just another version. (Restoring changes the draft, so it’s owner-only — see Ownership.)

Because each version is rebuilt through the gated pipeline, restoring or publishing an older version is always render-checked too, so you can’t accidentally publish a version that no longer renders.

​

Ownership and permissions

The permission model is the same as Classic: every app has one owner, refreshes run the app’s pipeline using the owner’s data connections (no matter who triggered them), and changing the app’s content is therefore reserved for the owner. Next Gen additionally distinguishes what the app’s editors (added under Settings > Editors), workspace Developers, and org admins can do:

• Owner: everything — canvas and chat editing, publishing, refreshing any version, restoring versions, settings, editors, delete.
• Editors, Developers, and admins: trigger Refresh now (the run still executes under the owner’s account), change settings and the schedule, publish a built version, and inspect the app’s drafts — see below.
• Everyone else: view the published app, star it, clone it, and ask questions in chat.

​

Inspecting without editing

Where the owner sees the Edit pencil, editors (and Developers/admins) see a History & source icon instead. It opens the same editor layout read-only: browse the version history, read the source code, and review diffs — with a READ-ONLY banner naming the owner. You can’t change anything from there, but the banner offers Claim ownership when you’re eligible, and Clone is always available in the ⋯ menu.

​

Claiming ownership

Claim ownership (⋯ menu, or the shortcut on the read-only banner) makes you the app’s owner, exactly as in Classic: future refreshes — including the existing schedule — run using your data connections, and the previous owner stays on as an editor. A confirmation dialog explains the consequences before you claim.

​

Sharing, publishing, and cloning

• Publishing to viewers: publishing a version (above) controls what content viewers see. Making the app discoverable in the workspace listing works the same way as Classic (see Publishing).
• Clone: create your own copy of any app you can view. The clone starts from the same pipeline and output with independent version history.
• Star: pin an app to your sidebar for quick access.