Every leadership dashboard hides a human ritual: someone exports the CSV, reshapes it, and pastes it somewhere visible. FluidGrids turns that ritual into a scheduled workflow whose final node is a dashboard feed.
Build the pipeline like any other workflow: a cron trigger for the cadence, source nodes pulling from your systems — HTTP APIs, databases, SaaS connectors — and internal transform and aggregate nodes shaping the payload. The tail of the workflow is where it gets interesting.
Append the native DataSink node as the terminal step. It supports five operations — posting data to all sinks linked to the workflow, posting via webhook to a specific datasink key, creating a sink from inside the workflow, and querying sink state — and its signature trick is auto-collection: leave the data field empty and it automatically captures the previous node's output. No manual mapping step between "computed the numbers" and "shipped the numbers".
On the dashboard side, datasinks are keyed destinations with TTL caching and refresh control. Widgets bind to a sink; when your workflow run lands fresh data, the sink's version increments, its status flips through refreshing to ready, and every bound widget repaints. Each delivery reports how many sinks updated, the payload size, and a data hash — enough to assert end-to-end delivery in a test, not just hope.
The result is a clean division of labor: FluidGrids is the ETL layer — scheduled, observable, retryable like any workflow — and the dashboard is the presentation layer. The morning the leadership dashboard updates itself, the CSV ritual is officially dead.
Do it yourself
Turn any workflow into a scheduled ETL pipeline by appending the native DataSink node, so a dashboard repaints itself on every run instead of waiting on a manual CSV export.
Create a workflow with a schedule trigger and source nodes that pull from your systems (HTTP, database, or SaaS connectors).
You should see: The extract half of the pipeline is on the canvas.
Ready to make this your story?
