Chart Templates and Releases
Reusing a chart across areas — releasing it as a template, the version contract, and why editing un-releases it.
Where the same dashboard shape repeats across areas — twelve lines each needing the same four charts — chart templates keep them consistent as they evolve. The mechanism parallels model templates, with one behaviour specific to charts that catches people.
Releasing a chart as a template#
A chart is made available as a template by releasing it. Releasing marks the chart as published, at its current version, and from that point other charts can be derived from it.
The eligibility rule is worth knowing before you try: a chart can only be released as a template when its content is template-linked — the measures and metrics it references are themselves template members rather than purely local model entities.
That follows from what a chart template is for. A chart hard-bound to Line 1's specific measures cannot be a template for Line 2, because those measures do not exist there. A chart bound to template measures can be, because each instance resolves them to its own.
Build the model template first. Chart templates sit on top of model templates. Template the metric and its measures, instantiate them, and then template the charts. Attempting the reverse produces charts that cannot be released because their content is local.
Editing un-releases and bumps the version#
This is the behaviour specific to charts, and it surprises everyone once.
Any edit to a released chart un-releases it and increments its version.
Move an axis, change a series colour, add a measure — the chart is no longer released, and its version has moved on. Nothing warns you at the moment of the edit.
The reasoning is sound: a released template should be a fixed, known thing. If it could be edited in place, charts derived from it would silently change beneath their owners. Making an edit produce a new, unreleased revision forces the change to be deliberate.
The practical consequence: after editing a chart template, you must release it again, and then update the instances. A change that stops at the edit has reached nothing.
Opening a released chart to look at it is not always harmless. Editing is what un-releases a chart — but the safest habit is to treat any session in a released chart's designer as potentially version-affecting. If you only want to see how a chart is configured, prefer listing its structure over opening its designer:
--list-chart-tree --chart-id <id>
The synchronised indicator#
An instance chart is synchronised when its local version matches the template version it was derived from.
That comparison is what tells you, across a large dashboard set, which instances have taken a change and which have not. After releasing a new template revision, the instances show as out of step until they are updated — which is exactly the visibility you want during a staged rollout.
The rollout sequence#
Getting a change from a chart template to twelve area dashboards:
- Edit the template chart.
- Release it again — the edit un-released it.
- Update the instances, in a scope you choose.
- Verify a sample: the change is present, and nothing else moved. 5 Check the synchronised state across the set to confirm which instances took it.
Steps 2 and 5 are the ones skipped. Skipping 2 means nothing propagates; skipping 5 means you do not know whether it did.
Staged rollout#
For a set of any size, update one instance first, look at it, then update an area, then the rest.
Chart changes are visible to users immediately and are the changes most likely to prompt questions, because a dashboard that looks different is noticed in a way that a corrected calculation is not. A staged rollout gives you a chance to discover that the new axis range is wrong on the area whose values run higher, before it appears on twelve screens.
Where charts differ from model templates#
Chart templating is deliberately narrower than model templating, and it is worth knowing the boundary so you plan around it rather than into it.
Available for charts: creating a chart template, releasing and un-releasing it, deriving instances, updating them, and the synchronised indicator.
From the command line in 7.2.0: charts can be released and un-released as templates from the CLI, which is new in this release and useful in a scripted build. The remaining template operations for charts — linking, delinking, instantiating, and synchronising — are performed in Flow Config rather than from the CLI, and there is no chart delete or chart export verb.
So a fully scripted model build can create charts, configure them, and release them as templates; the instantiation and update of chart instances remains a Flow Config activity. Plan a build script around that boundary. See Authoring Charts from the CLI.
Sharing charts without templates#
Templates are not the only way to reuse a chart, and sometimes they are the wrong one.
One chart on several dashboards. A chart is referenced by panels, so a single plant-wide OEE chart can appear on the executive summary, the plant overview, and an area page. Configured once, changed once. Remember the corollary: editing it changes it in all three places.
Export and import. A one-time copy of a dashboard's worth of charts into another instance. Independent afterwards — improvements to the source do not reach it. Good for a one-off transfer, poor for something you will maintain. See Importing and Exporting Models.
Templates. For a pattern that repeats and will be maintained centrally over time.
The decision is the same as for model content: if you will improve it repeatedly and want the improvements to reach every copy, template it. If it is a one-time transfer, copy it.
Verify after importing charts#
Chart import resolves references — measures, dashboards, folders, limits — from the source instance to the destination. That resolution depends on the scope of the export matching the scope of the import.
After importing charts, check before relying on them:
- Charts arrived with their components and series, not empty
- Series resolved to the intended measures in the destination
- Limits bound, where the source had them
- Panels on dashboards reference the right charts
An import scoped to charts behaves differently from a full model import. An export taken at chart or dashboard scope is treated as a chart import on the way in, which changes how references are resolved. If charts arrive without content, or an import fails partway through mapping, the scope of the original export is the first thing to check. Import into an empty area on a test instance when you are unsure.
Diagnosing#
| Symptom | Cause |
|---|---|
| Cannot release a chart as a template | Its content is purely local; template the measures first |
| Template edit did not reach instances | The edit un-released it; release again, then update |
| Instances show as out of step | A new template version exists and has not been rolled out |
| A chart changed on a dashboard nobody edited | The chart is shared across dashboards |
| Version incremented unexpectedly | The chart was edited while released |
| Imported charts are empty | Export scope; verify against the source and re-import at model scope |
| Series point at the wrong measures after import | Mapping resolved differently in the destination — verify a sample |