Roadmap none of this page is shipped; release dates are not announced
This page describes the plans for these three features. None of this page is shipped; release dates are not announced. What ships today is the half these features stand on: a released pipeline, published as a versioned endpoint, that a dashboard would consume and an extract would materialise. Everything below says roadmap, planned, or later — in as many words.
Last updated 2026-09-16
Planned
The roadmap's own words: "dashboards, created by your agent, you embed in your own product, fed by released pipelines and APIs, filtered per viewer." Each clause is a decision. Created by your agent — the same authoring surface that drafts a pipeline today. Embedded in your own product — not a hosted portal you send people to; the chart lives behind your login. Fed by released pipelines and APIs — the numbers are the ones a person released, not a query someone retyped.
Filtered per viewer means: a value bound from the viewer's request — session or key — becomes a declared parameter of the released pipeline, and the released SQL filters on it. The same dashboard, every viewer, their own rows. That mechanism is not roadmap: declared parameters bind as prepared-statement values in the released pipelines served today, which is what the dashboard feature will consume.
The shape of the feature follows from the wording, and it is worth reading the clauses as commitments: "fed by released pipelines" means the dashboard cannot show a number that did not come from a version a person released — the audit trail of a chart is the audit trail of a pipeline. "Embedded in your own product" means there is no second portal to log into, no copy of your users to manage, and no hosted tier — the chart renders where your users already are. And "created by your agent" means the authoring loop is the one that already works: schemas in, draft out, run checked, person releases.
Later · decided, not dated
The roadmap item: a scheduled pipeline materialises its result as Parquet on your own S3 bucket — the lake you already own becomes the extract store, with no second copy of the data anywhere else. Tableau reads Parquet natively, so the extract lands where the drawing tool already looks. Two pieces, in order: the scheduler is the planned roadmap item — schedules in folders, fired exactly once across instances, every run a first-class execution — and the extract itself is later, decided but not dated. Until it ships, write-back can land a result in a datasource table a BI tool connects to, and the lake reads Parquet and Iceberg on S3 in place.
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. When the item ships, the extract's shape is the write-back node's contract pointed at object storage: a released pipeline's result, landed where a drawing tool already reads.
Later · decided, not dated
The roadmap item in full: a scheduled pipeline, a condition, an email. When a released pipeline's result crosses a threshold you set — a number too low, a load too high — the schedule fires, the condition decides, an email arrives. Email only. Nothing else is promised until it exists; there is no Slack connector on any roadmap, and the "what this is not" section below says so in as many words.
Notice what the alert inherits from what ships: the number it watches is a released pipeline's output, so an alert that fires is traceable to a version, a run and a result — not to a query somebody's laptop was kind enough to finish. That inheritance is the design's whole argument, and it is why the item sits behind the scheduler on the roadmap rather than beside it: alerts without schedules are cron with opinions. Until both ship, the closest honest substitutes are the ones already on this page — a scheduled run a person checks, or an endpoint a monitor polls — and they keep the audit trail an alert would want.
The fence
Drawing, workbooks and Tableau's own governance stay Tableau's. The roadmap items here are the three things Tableau users keep asking the pipeline to do — embed, extract, alert — not a suite to migrate to, and the Tableau page keeps today's column honest.
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; dashboards "embedded in your own product" means your product, on your stack.
If the thing you wanted the dashboard for is "customers see their numbers in our app", the endpoint ships today: released pipeline, versioned GET, keys scoped to a path, parameters bound per viewer. The dashboard is a consumer of that contract, like any other.
Ships today what the roadmap stands 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. The dashboard feature consumes exactly this contract.
Declared parameters bind as prepared-statement values today: the viewer's key or session supplies the value, the released SQL filters on it. "Filtered per viewer" is a UI over a shipped mechanism, not a new engine.
A node can land its result in a datasource table today — the pattern a scheduled extract generalises to Parquet on your own bucket. One is shipped, one is planned; this page keeps the two apart.
JSONata and JavaScript transform nodes — the shaping SQL is bad at, the pivot Prep did with a click — are the planned roadmap item beside the scheduler, with a design record on disk. Named as roadmap here; this page does not describe designs as shipped.
Asked before
No — they are planned, with no announced release date: dashboards created by your agent, embedded in your own product, fed by released pipelines and APIs, filtered per viewer. What ships today is the released pipeline and the GET endpoint a dashboard will consume. The endpoint contract is docs/rest-api.md §19.
Later — decided, not dated. The scheduler that would run them is the planned roadmap item; the extract itself would land a Parquet file on your own bucket, which Tableau reads natively. The scheduler design is docs/superpowers/specs/2026-09-07-scheduler-design.md.
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 roadmap item is docs/ROADMAP.md §3.
That the same dashboard shows each viewer their own rows: a value bound from the viewer's request becomes a declared parameter of the released pipeline, and the released SQL filters on it — the binding mechanism released pipelines already serve today. Binding is docs/templates.md §4.5.
Every item on this page consumes the same contract that ships today. Publish the endpoint now, and the dashboard, the extract and the alert each become an addition — not a migration.