Smart Charts

Every other node in this module changes something in your CRM. This one draws a picture of it. Give it rows — from a Database Query, a Sheets pull, an API response — and it returns chart JSON: which chart to use, the series to plot, and a summary of what it found.

The interesting part is what it does not ask you. There is no chart-type setting. You do not tell it which column is the axis. It looks at the array, works out which columns are categories, which are dates and which are numbers, and picks accordingly — a bar chart for categories against a metric, a line for anything over time, a pie for parts of a whole.

That decision is made by rules, not by a model. No prompt is sent anywhere, nothing is billed as a completion, and the same data produces the same chart every time. In a path full of AI nodes, this one is worth noticing precisely because it is not one.

data_input is the node. It takes a template reference to an array of records from upstream — rows from a query, items from an API response, anything that resolves to a list of objects with the same keys. If that resolves, the node works; if it resolves to something else, nothing else you configure will save it.

Of the other six, two change what you get rather than how it is computed. multi_chart is on by default and produces one chart per categorical column, up to max_charts; turn it off when you want exactly one picture. max_categories caps how many slices or bars appear before the rest are grouped into an Others bucket — which is why a pie chart of fifty stages does not come back with fifty wedges.

Monday morning, count the deals in each stage and chart them. The query does the grouping; the chart node does not need to be told that stage is the category and the count is the metric.

Two things in that diagram carry the lesson. result_format on the query is set to return an array of objects — that is the shape Smart Charts expects, and a query returning anything else gives it nothing to read. And multi_chart is off, because this workflow wants one picture of the pipeline rather than one per column.

Nothing chartable. If no column in the array is numeric, categorical or temporal — a list of ids and free-text notes, say — the node returns a NO_CHARTABLE_DATA error rather than an empty chart. That is the honest behaviour, and the fix is upstream: select a column worth counting.

The wrong shape. The commonest failure is not the chart, it is data_input resolving to a single object, a string of JSON, or a wrapper around the array rather than the array itself. data_summary tells you what arrived; read it before adjusting anything else.

A chart of raw rows. Handing over ten thousand unaggregated rows works — auto_aggregate groups them — but the chart it produces is a chart of whatever grouping the node inferred. If you know what you want counted, count it in the query. A GROUP BY upstream produces a better picture than any setting on this node.

Reach for a dashboard when the same question gets asked every week by the same people. Reach for this node when the question arrived inside a workflow and the answer is better as a picture than as a number.