Different teams. The same data problem.
Make the data useful
to the people who need it.
Start with one recurring question, one application endpoint, or one dataset your BI team keeps rebuilding. These examples show where datapipelines can fit.
Business operations
Which orders still need attention?
Sales sits in one database. Fulfilment lives in another. Ask for a combined view your team can inspect before its next decision.
Agree on what counts as fulfilled, join the relevant records and review the totals. Save the pipeline with a reporting-period parameter, then run the same logic for the next review.
Weekly orders by region
| Region | Orders | Fulfilled |
|---|---|---|
| North | 1,240 | 94% |
| South | 980 | 91% |
| West | 1,110 | 96% |
Fictional figures to illustrate a use case, not a customer result or native dashboard.
Product teams
Put customer usage inside your product.
Combine usage and account data into a reviewed pipeline, then publish it as an API. Your backend requests the data; your product controls how customers see it. Each call runs released SQL without another AI authoring step.
Your backend controls customer identity and parameter values. Endpoint keys restrict allowed paths; they do not automatically turn arbitrary customer IDs into row-level authorization.
Embedded analytics for SaaS teams · A reporting API per client
Your product. A useful data endpoint.
GET /api/x/product/usage
{
"period": "2026-08",
"active_seats": 28,
"requests": 18420
}
Fictional endpoint and output showing the integration pattern. The chart or customer screen is built in your application.
Analytics teams
Prepare the dataset once.
Use it where you already work.
Use one reviewed pipeline for the revenue dataset behind your Tableau workbook. Keep the chosen exclusions and definitions with the data, and reuse versioned SQL templates as more reports need the same logic.
Write the result into a database Tableau connects to, or connect to the published API through an appropriate web data connector. Run the pipeline when you need an updated result; native scheduling is planned.
Using datapipelines with Tableau · A governed dataset, step by step
Data preparation is available today. Visualization remains in Tableau or your own application.
Is it a fit?
Best when your team needs control over the answer.
A good starting point: supported databases, someone who can run the server, and a recurring question worth turning into a reviewed dataset.
If you need a hosted, ready-made dashboard with no technical setup today, this beta won’t meet that need yet.
See the setup and workflowAsked by each team
Three questions before you start
Do I need to move the data into a warehouse first?
No. A pipeline reads each source where it lives and joins across sources in a temporary staging database that exists only for the run (docs/staging.md §3). If you want a copy, a node can write its result back to a database you choose (docs/pipeline-contract.md §8) — that is a choice, not a prerequisite.
Can my product show each customer only their own data?
Your backend does that: it supplies the customer's identifier as a declared parameter and holds the endpoint key (docs/rest-api.md §19.3). The key restricts which published paths may be called (docs/auth.md §7.7); it does not turn an arbitrary customer id into row-level authorisation, so the check stays where your product already makes it.
Can I use it with Tableau today?
Yes, for the data preparation: a released pipeline serves a versioned JSON endpoint (docs/rest-api.md §19), or writes its result into a database Tableau already connects to (docs/pipeline-contract.md §8). Visualisation stays in Tableau or your own application; native dashboards and scheduled refresh are planned (docs/ROADMAP.md §2).
Start with one question your team needs answered.
Explore the sample data first. Connect your own databases when you’re ready.