Dashboards ship extracts and alerts are later; release dates are not announced
Three things Tableau users ask a pipeline to do: show a chart inside their own product, refresh an extract on a timetable, and send an alert when a number moves. Dashboards ship today, and so does the scheduler that reruns a pipeline. Scheduled extracts to your own bucket and condition alerts by email are later, with no announced release date. Each section below says which one it is.
Last updated 2026-10-25
Ships today
A dashboard here is charts, tables and KPI cards over pinned versions of released pipelines. Your agent drafts the visualizations and the dashboard with the same authoring tools that draft a pipeline, and a person reviews the draft in the application and releases it. A visualization releases only with passing test evidence for its exact content, so the chart a customer sees is one a person checked.
Embedding goes through your own backend. It holds a dashboard key and relays the dashboard's
runtime routes; the key is attached server-side and never reaches the browser. The source includes a
dependency-free reference proxy you place behind your own sign-in. The chart renders behind your login, on
your page, with no second portal for your customers to learn.
Per viewer is your backend's decision. Every viewer behind one key shares that key's identity and budget, so the key does not separate one customer from another. Your backend decides which filter values a viewer may submit; those values bind as declared parameters of the released pipeline, and the released SQL filters on them as prepared-statement values, never pasted text.
The limits are on the dashboards page too: a dashboard refreshes when its configured refresh actions run, a schedule does not refresh it, there is no drag-and-drop editor, and its read-only rule is declared by the source nodes' types rather than enforced by a read-only database connection.
Which one to reach for. Keep Tableau for analysts who explore: ad-hoc workbooks, drag a field onto a shelf, a server full of published views your organisation already governs. Reach for a dashboard here when the audience is your customers inside your product, the charts are a known set a person can review before release, and the numbers must trace back to a released pipeline version. Bar, line, scatter, pie, histogram, box and heatmap charts, tables and KPI cards cover that kind of embedded reporting. When your own front end should draw the chart, skip the dashboard and call the published endpoint for the rows instead.
Later · decided, not dated
The later item: a scheduled pipeline materialises its result as Parquet files on your own S3 bucket, in the layout the lake already reads. The lake you already own becomes the extract store, with no second copy of the data anywhere else, and Tableau reads Parquet natively. dp-lake has no write path to object storage today, so this is decided and not dated.
Half of it already exists. The scheduler ships: a schedule runs a pipeline at a cron pattern's times in your time zone and records every run. A pipeline with a write-back node lands its result in a table of a datasource Tableau already connects to, so a nightly refreshed table is a schedule plus a write-back today. What waits is the object-store target.
Why your own bucket, and not a managed extract store? The same reason the rest of the product runs on your infrastructure: the extract is your data, in your bucket, under your retention rules and your access rules: the server holds the schedule, the bucket holds the bytes, and either can be audited without the other.
Later · decided, not dated
The later item in full: a scheduled pipeline, a condition, an email. When a released pipeline's result crosses a threshold you set, the condition decides and an email arrives. Email only. Nothing else is promised until it exists; there is no Slack connector on any roadmap.
The scheduler and its run notices ship. When scheduler mail is enabled and recipients are configured, selected run events queue a notice, with failed, unknown and blocked events on by default. A condition on the result is a separate, later piece. Until then a person reads the schedule's run history, or a monitor polls a published endpoint, and both keep the audit trail an alert would want.
The fence
Drawing, workbooks and Tableau's own governance stay Tableau's. A dashboard here is a reviewed document an agent writes, without a drag-and-drop editor or a workbook gallery. The Tableau page keeps today's two columns apart.
The alerts roadmap item is email, and the roadmap names nothing beyond it. A Slack connector is not planned, and this page will not pretend a maybe is a feature.
Self-hosted, one Docker image, your infrastructure, AGPL-3.0. A hosted offering is not on the roadmap; a dashboard embedded in your product means your product, on your stack.
If what you wanted is "customers see their numbers in our app" in your own UI, the endpoint serves the same released pipeline as JSON: a versioned GET, keys scoped to a path, parameters bound per request.
Ships today what the later items stand on
Release a pipeline, publish it under a path, and a GET serves the released version with bound parameters as typed JSON. Cache-Control: no-store, keys scoped to the path. A dashboard and an endpoint can both read the same release.
Declared parameters bind as prepared-statement values: the caller supplies the value, the released SQL filters on it. Who may supply which value is decided where the viewer is signed in, in your backend.
A node can land its result in a datasource table, and a schedule can rerun that pipeline nightly. The extract later generalises this to Parquet on your own bucket. One is shipped, one is later; this page keeps the two apart.
A SCRIPT node runs a versioned JSONata or JavaScript template over staged rows, for the nested shaping and the pivot Prep did with a click. JavaScript is not Node: it runs in an isolate the Docker image includes.
Asked before
Yes. Your agent drafts visualizations and dashboards over pinned released pipelines, a person reviews and releases them, and your product embeds one through its own backend, which holds the dashboard key so it never reaches the browser. There is no drag-and-drop editor. The contracts are docs/dashboards.md §1 and docs/dashboards.md §6.5.
Later, decided but not dated. The scheduler that would run them ships, and a scheduled pipeline can already write its result into a table Tableau connects to; the extract itself, a Parquet file on your own bucket, waits on a write path to object storage. The contracts are docs/ROADMAP.md §3 and docs/scheduler.md §1.
No. The roadmap names email alerts and nothing beyond them: a scheduled pipeline, a condition, an email. Later, not dated, and deliberately no Slack. The planned alerts are docs/ROADMAP.md §3.
That each viewer sees their own rows because your backend decides which filter values a viewer may submit. Every viewer behind one dashboard key shares that key, so the key alone separates nobody; the allowed value binds as a declared parameter of the released pipeline and the SQL filters on it. The contracts are docs/dashboards.md §6.5 and docs/templates.md §4.5.
The dashboard, the schedule and the endpoint all read the same released pipeline. Release one now, chart it, run it nightly, and the extract and the alert each become an addition later, not a migration.