heat-system-next-dimension
Platform reserved (system-utils only). Aggregates upstream JSON containing canonical $heat-dataservice, writes it to object storage, and creates or updates a session dimension with DashboardVersion="Next" for ui/dashboard.
When to use it
Use in shipped platform session templates (for example tabular CSV dashboards or Resource Monitor) where HEAT owns the layout and payload pipeline. Integrators building custom analytics should use dashboard-v2 on dashboard-utils instead.
Limitations
- Does not target
ui/legacy(use heat-system-legacy-dimension). - Payload and layout rules match
dashboard-v2; invalid realms or layout fail the node. - Set
layoutFromParentOutput: true to takesuggestedLayoutConfigurationfrom system-tabular-to-dataservice whenemitSuggestedLayoutis enabled.
Scenario instance and users
Scenario handling follows dashboard-v2 so both dimension kinds agree on a session:
- One scenario per session. With
autoCreateScenarioInstanceand noscenarioName, the first dimension node to run creates the scenario and records it in session metadata (ScenarioInstanceId); later nodes reuse it. Name precedence:scenarioName, session metadatascenario_name, thenscenario_title, thenauto-dashboard. Templates setscenario_namefrom their own analytics (for example asystem-arbex-jsnode viactx.session.metadata.set). - Span.
scenarioFromIsoKey/scenarioToIsoKeypaths in the parent payload, else the session’s ownstartTimeUtc/closedAtmetadata (open sessions usetimeWindowSeconds), else an ISO-8601 scan of the payload. The scenario this node created is re-inferred on every run, so a span guessed before data arrived follows the data afterwards. - Users.
dashboard_usersin the payload (HEAT Auth or capture-origin GUIDs) is mapped onto the session’s registered users; unknown ids are ignored. Session users are registered upstream by the runners that know the participants (see dashboard-v2 upstream contract).