A chart and a grid share one query: click a bar and the grid filters to its rows; edit a cell and the chart redraws; switch the hierarchy chip and both roll up differently.
| Type | Use | Linked to |
|---|---|---|
| Bar and column | compare categories or periods | grid rows per bar |
| Line and area | trends over time from the pivot's time axis | grid rows per point |
| Scatter | two measures per entity: late rate against spend | one row per dot |
| Heat map | a matrix of two dimensions with a measure as colour: plant × month | grid rows per cell |
| Treemap | shares in a hierarchy: revenue by family and group | grid rows per block |
| Small multiples | one chart per node of a hierarchy level | grid rows per panel |
| Sparkline | a trend inside a grid cell | the cell's rows |
| Gauge and tile | a measure against a target from a rule | the rule's rows |
A story is for reviews: supplier performance, demand against plan, data-quality trend by domain. Each step is a view with a note, and the sequence is tied to a data version, so the reader sees what the author saw and can open the rows behind any chart. Because the grid is on the page, the story shows the picture and the numbers, and a sceptical reader drills on the same page.
Stories are shared like any view, with the same security: a reader with a narrower row filter sees a narrower story, and the audit trail records who read what.
For enterprise reporting, keep it and point it at the same query through SQL. The charts here are for the people who govern and analyse master data on the page where the data is.
Yes; a published attribute or a saved query is a source for a pivot, and a pivot is a source for a chart.
A story with one step and several charts is a dashboard; it refreshes on open and can be pinned.
Bring two systems that hold the same customers, suppliers or materials. In one working day we connect them, run the match on live rows, review the queue with your steward and publish the first golden view with its API.
