DataFuseAI for Analytics Teams
The same joins, the same region filter, the same margin column — rebuilt by hand for the same report, again this week. Underneath it: why do these two dashboards disagree?
DataFuseAI moves report preparation into a scheduled pipeline: the joins, filters, and derived fields are defined once, so every report starts from the same table. Aggregate and Pivot shape it to the grain and column layout the BI tool expects, and a profiling step reports distinct, null, minimum, mean and maximum per column on every run.
Day one: connect one source, build the pipeline, and schedule it as a job.
Rebuilt Again, and the Number Nobody Can Defend
Four things usually run at the same time on your team: the same dataset reconstructed by hand every cycle; two dashboards reporting the same metric differently because each workbook re-derived it; a duplicate or an unexpected null reaching a published number before anyone checks it; and a refresh that arrives on someone else's clock. None of the four is a mistake anyone made once — each is what happens when the logic lives in a workbook rather than in a pipeline.
The dataset you rebuild before you can start the analysis
Export, paste, join, filter, add the two derived columns. Then do it again next cycle, because the steps live in your hands rather than anywhere they can be re-run. The work that produces the table is repeated in full every time the table is needed — and the analysis starts only after it is done. We have costed this: what a weekly rebuild in spreadsheets actually costs.
Two dashboards, two answers, and nobody can say which
Both were built from the same source. The metric was re-derived in each workbook — one filtered the cancelled rows, the other did not — and the definitions were never written down anywhere both could read. Correcting it means finding every workbook that re-derived the field, because there is no single definition to change. The prior question: what to do when two systems disagree about the same field.
The wrong number, found by whoever was reading it
A join duplicated rows, or a field started arriving empty. The dashboard published anyway, because nothing in the path was checking the shape of the output. The person who found it was reading the number, not building it — so the first you hear of it is a question, not an alert. That is how a wrong number reaches the people reading it.
The refresh that runs on someone else's clock
The table lands when the upstream job lands, or when somebody remembers to run the extract. Your report inherits that timing whether or not it suits the decision it feeds, and a monthly rollup and an operational table end up on the same clock. By the time the dashboard is read, the freshest thing on it is the timestamp. Settle which refresh cadence a report actually needs.
The steps are correct. They just have nowhere to live between runs.
What Moves Into the Pipeline, and What Stays Yours
The pipeline takes over the reconstruction: the joins, the filters, the derived fields, the shaping into the grain and column layout the dashboard needs, and the per-column check that runs each time it refreshes. What stays yours is every judgement with a consequence — which key actually joins cleanly, what the metric means, and how often the answer has to change.
The dataset is built once and produced the same way every run
The joins, the filters, and the derived fields move out of the workbook and into a pipeline definition. Run it, and the table is produced the same way every time — so every report that reads it starts from the same numbers rather than from each analyst's own reconstruction. Where a definition changes, it changes there. That output is the analytics-ready table your reports read from.
The BI tool receives a table, not a modelling problem
Join and Union consolidate the sources. Aggregate rolls the rows up to the grain the report needs, and Pivot produces the column layout the dashboard expects. The shaping is stored in the pipeline rather than in the dashboard, so the modelling step is already done when the BI tool receives the table. Power BI and Tableau both receive a table on those terms. These are the transformations that shape the output.
Schedule it once, then query the result
Instead of rebuilding the same report by hand every week, schedule it once and query the result. Scheduling a pipeline makes it a job that runs on its own cadence — minute, hour, day, week, or month, and each job carries its own schedule, so an operational table and a monthly rollup need not share a clock. The landed table stays queryable in the Query Editor, so checking what the run produced does not require the dashboard.
Check the numbers before the dashboard is published
A profiling step reports, per column: data type, distribution, distinct, non-distinct and null counts, minimum, mean, maximum, cardinality, sum, and standard deviation. A sum you can check against a total you already know catches a join that duplicated rows before the dashboard is published. Because the pipeline is scheduled, the check repeats on every refresh rather than only when someone thinks to look. These are the checks that run inside the pipeline.
What Becomes Reusable, and What Becomes Checkable
Every item here is something you can open during a trial and look at: the pipeline definition, the transformation steps on the canvas, the profiling output for a run, the Query Editor, and the job's schedule. None of it is an outcome you take on trust.
The joins, filters, and derived fields live in one scheduled pipeline — every report reads the same table instead of each analyst rebuilding it in their own workbook.
Join, Union, Aggregate and Pivot shape the output to the grain and column layout the dashboard expects — and the shaping is stored in the pipeline, not in the workbook.
A profiling step reports type, distribution, distinct, non-distinct and null counts, minimum, mean, maximum, cardinality, sum and standard deviation per column — on every scheduled run, not only when someone looks.
Landed tables stay queryable in the Query Editor, with SQL running against the sink engine your output lands in — exploring a question does not require building a pipeline first.
A changed source column is corrected once and every downstream report inherits the fix — and each job carries its own schedule, from per minute to per month.
From Teams Already Running on DataFuseAI
These are DataFuseAI customers describing the platform in their own words. We have not filtered them by role or by job title.
"We used to manage dozens of scripts across servers. Any change — a driver update, credential change, or schema tweak — broke something. Moving to DataFuseAI meant pipelines, jobs, and connection profiles now live in one place. It didn't just eliminate complexity — it also made things visible and manageable, which is a huge difference."
"Scheduling used to be the weak link. A cron misfire or a missed run meant downstream reports were wrong and nobody noticed. With jobs, alerts, and the dashboard, we see failures early, and the team trusts the numbers again. There are still custom workloads we run on Databricks, but DataFuseAI coordinates the day-to-day work cleanly."
"Our analysts were constantly blocked waiting for the engineering team. With visual pipelines and saved queries, they can build and view most of what they need themselves."
"We deploy in environments with strict compliance requirements. For us, the tenant model and offline / on-premise option mattered. We can isolate data, control permissions at a fine level, and still give teams a single place to operate pipelines and queries. It's not 'magic,' but it's practical — and audit conversations are easier now."
Frequently Asked Questions for Analytics Teams
Move the preparation into a scheduled pipeline and query the result. Once the joins, filters, and derived fields live in a pipeline, the table is produced the same way every run and every report starts from the same numbers — instead of each analyst re-deriving them and arriving somewhere slightly different.
Yes — that is what the transformations exist for. Join and Union consolidate the sources, Aggregate rolls rows up to the grain the report needs, and Pivot produces the column layout the dashboard expects. The BI tool then receives a table rather than a modelling problem, and the shaping is stored in the pipeline rather than in the dashboard. The same pattern is written up for preparing the table Power BI expects and for shaping the same table for Tableau.
Profile it. A profiling step reports per column: data type, distribution, distinct, non-distinct and null counts, minimum, mean, maximum, cardinality, sum, and standard deviation — so duplicates, unexpected blanks, and implausible values surface before the dashboard is published. Because the pipeline is scheduled, those checks repeat on every refresh.
Yes. Landed tables are queryable in the Query Editor with SQL running against the sink engine, so ad-hoc investigation does not require building a pipeline first. The usual pattern is to explore in SQL, then move whatever proves useful into a scheduled pipeline so it stops being ad-hoc. That is what exploring a question without filing a request looks like in practice.
The pipeline is one place to fix rather than many. Because the join logic and field definitions live in the pipeline instead of in each workbook, a changed column is corrected once and every downstream report inherits the fix — and profiling the output is what tells you the change happened before the numbers move.
As often as the decision requires. Jobs can be scheduled by minute, hour, day, week, or month, and each job carries its own schedule — so a fast-moving operational table and a monthly rollup run on separate clocks without duplicating the transformation logic between them.
They are rebuilt as pipeline definitions rather than imported as files or formulas — the same honest answer any change of platform gives. What you get back for that is that the logic stops living inside one person's workbook: the joins, the filters, and the derived fields become steps someone who did not build them can open and read. The report itself is then produced by a scheduled job rather than by whoever has the file open.
Take the single report you rebuild most often, end to end, rather than migrating the reporting estate. Each source it touches needs one connection profile, registered once and reused, and the pipeline, the schedule, and the profiling output that follow are the whole shape of the platform in miniature. The second report goes faster than the first because the field definitions are already settled — which makes the second one the real test. That is the same logic as evaluating with one workload before committing to a platform.
Yes — a dashboard that has to react to an event the moment it arrives. Jobs run on a schedule and the finest cadence is per minute, so there is always a cycle between the event and the number on screen. This is scheduled batch work with a recorded run per cycle, not a stream. If your dashboard's whole value is reacting inside that window, it is cheaper to know that now.
Where to take your reporting next
The report built once, and produced the same way every run
Move the joins, filters, and derived fields out of the workbook and into a scheduled pipeline, let Aggregate and Pivot shape the output to the grain and column layout your dashboard expects, and read the profiling output for that run before anyone reads the number on the dashboard.