The Studio is where a measure becomes something you can look at. No SQL, no table names, and a deliberately opinionated set of choices.
What you pick
A source. What kind of record: deals, invoices, people, tickets. Searchable, so you do not need to know what it is called internally.
A measure, or an aggregation over a field. Existing measures are the better choice: they carry a governed definition, and picking one means your chart agrees with everybody else's.
A dimension, if you want a breakdown. By owner, by stage, by month.
A scope. Which records count, and over what period.
A shape. The chart.
It offers what works and refuses what does not
The list of charts you can pick changes with what you have chosen, and it is worth understanding why rather than fighting it.
A field's type decides the arithmetic. Count applies to anything, since it counts rows. Sum and average need a number. Minimum and maximum work on numbers or dates, where they mean earliest and latest. A status field supports only count and count of distinct values, because averaging a status is not a thing.
A dimension's spread decides the chart. A field with six values makes a reasonable pie. One with forty does not, and it is not offered. A trend needs something time-shaped on one axis.
A table is always available. When nothing else fits, that is the honest answer rather than a bad chart.
This is the single most useful constraint in the surface. Most misleading charts are made by tools that let you make them, and the same rules apply in the studio, in the query engine and in the board seeder, so all three agree about what is offerable.
Scope
Two parts, and they are frequently confused.
Which records. Filters. One pipeline, one hub, one status.
Which period. The time window.
For a flow measure the period is part of the question, and changing it changes the answer proportionally. For a snapshot it is a different thing entirely: you are asking what the value was, not what accumulated. The measure carries that distinction so the engine handles it, which is the reason the class is declared on the measure rather than guessed here.
Heroes
The studio can suggest a lead widget for a source: the one number most worth showing.
Those suggestions come from the same rules that decide which charts fit, so they are reasonable rather than clever. Take one as a starting point when you are new to a data source and do not yet know what it holds.
They are a shortcut, not a recommendation about your business. Nothing here knows which number your organisation should care about.
Preview before saving
The result renders live as you change things.
Two things worth looking at every time, because both are invisible until you check.
Does the total match somewhere you already trust? If revenue here disagrees with Finance, one of them is wrong and it is much cheaper to find out now.
Is it empty, and if so why? An empty widget has causes, and the surface will tell you which. That is covered in the piece on reading a widget.
The chart types
Beyond the obvious bar, line and table, the studio offers area, pie and donut, scatter, radar, horizontal bar, stacked forms, combination charts and heat maps.
The list you see is filtered by what your data supports, so it will rarely be all of them.
Two worth knowing about because they are underused. A heat map handles two dimensions and a measure without the crowding a cross-tab gets. A combination chart puts a count and a value on one frame, which is the honest way to show volume beside size.
Saving
A widget can be saved to the library, where it is available to put on any board, and it can be added to a board directly.
Save to the library when you have built something reusable. Add straight to a board when it answers one board's question and nowhere else.
Both create a real, governed widget rather than a snapshot of numbers, so it re-runs against live data every time somebody opens it.
Describing what you built
There is a bar that puts the chart into a sentence.
Worth using on anything going in front of other people. A chart title says what was measured; the description says what it shows, which is a different and more useful thing for the person who arrives at the board cold.
Naming a widget
Same discipline as measures, and the same reason.
Say the scope in the name. "Pipeline by owner, this quarter" beats "Pipeline". The board shows the name, and a reader will assume a scope if you do not give one.
Do not name it after the question that prompted it. "Why is the north region down" is a moment, not a chart.
Filters, precisely
Two things narrow a widget and they behave differently.
A filter removes records. Only this pipeline, only this status, only these hubs.
A period removes time. It interacts with the measure's class, which is why the class is declared once on the measure rather than guessed here.
A trap worth naming: a filter on a value that does not exist produces an empty widget rather than an error, because an empty result is a legitimate answer to a valid question. If a chart is unexpectedly blank, check the filter before anything else.
Building one you will still trust in March
Name the scope in the title. The board shows the name and nothing else.
Verify against something you know. Build the first widget for a number you can check by hand.
Prefer a measure to an ad-hoc aggregation. An aggregation typed into a widget is a private definition nobody governs, and two of them will disagree eventually.
When the studio is the wrong tool
For a cross-tab, a funnel, a correlation, an analysis or a basket, use the dedicated engine. Each has its own piece and each produces a first-class widget that sits on a board alongside anything built here.
For a list of records rather than a number, use Reports. A table of every open invoice is a report, not a chart, and the two surfaces are shaped for their jobs.
Did this answer your question?
No, ask a person