Create Scenario

Combine records from Map nodes into a saved scenario you can analyse, visualise, and compare.

When to use this¶

Save records produced by the installed package's mapping nodes.
Keep the output of a node that produces scenario data.
Save a new copy of a loaded scenario.

What you need¶

Connect compatible upstream nodes to the scenario input. The installed package declares which record types it accepts, how they become stored tables and which validations apply. Read the mapping node's documentation for its fields and the analysis node's requirements for the tables it needs. Discover available nodes through the catalogue.

Parameters¶

Parameter	Default	Description
Scenario Name	—	Required. Shown in the scenario list. Use descriptive, outcome-oriented names. At most 200 characters. A missing, blank or longer name is reported on the node when the workflow is saved and refused by Validate and Run.
Scenario Description	—	Optional free text, shown whole beside the scenario wherever it is listed. Useful for capturing assumptions ("Q3 assumptions, revised prices"). At most 600 characters, the length every description in the product is held to.
Horizon Start	—	Optional first day of the planning window, as an ISO date (`YYYY-MM-DD`).
Horizon End	—	Optional last day of the window, as an ISO date. Must not fall before Horizon Start when both are supplied.
Unit	—	The unit the scenario's quantities are reported and optimized in, such as `kg` or `pallet`. Required once the scenario carries quantities; it is never taken from the data.
Currency	—	The ISO 4217 currency of the scenario's money values, such as `EUR`. Required once the scenario carries money values — costs, prices or revenue; it is never taken from the data.
Emissions Unit	—	Unit of every emissions figure in the scenario, such as `kg CO2e`. Required once the scenario carries emissions; leave it blank only when it carries none.

The currency setting labels the money values the workflow produces; it does not convert them. A scenario that carries money and no Currency is refused, naming the tables and rows that carry it; one that carries no money needs none. Every Create Scenario node states it, including one that saves an optimized scenario. To convert currency, apply an explicit exchange rate to the amounts in the workflow and save a new result. To change the planning window, recompute the relevant data and save a new result. A saved scenario's currency and horizon cannot be edited or cleared; only its name and description can be changed, on the Scenarios page (Edit details in the scenario's menu). Dashboards keep referring to the original scenario until their selection is explicitly changed.

The scenario's unit¶

A scenario is reported and optimized in one unit, the Unit stated here. Optimized quantities are written in it.

Your data does not have to be in that unit. Every row that carries a quantity, or a rate per unit such as a cost per pallet, states the unit it is in, and the scenario keeps the rows exactly as you uploaded them. Where a row's unit is not the scenario's, a conversion for the row's product has to connect the two; conversions are mapped with Map Units & Conversions.

Nothing is assumed, and the run is refused, naming the table and rows, when:

the scenario carries quantities and Unit is blank;
a row carries a quantity or a rate per unit and states no unit;
a row's unit has no conversion to the scenario's unit for its product;
the conversions themselves are incomplete or contradict each other.

Every Create Scenario node states the unit, including one that saves an optimized scenario.

The emissions unit works the same way: it labels emissions without converting them. A scenario keeps its emissions in one unit, because they are added up across lanes. The unit is stated here and never taken from the data: a scenario that has emissions and no Emissions Unit is refused, also when every row states the same unit. Rows that state their own unit must state this one, and the run is refused when they disagree. Every Create Scenario node states it, including one that saves an optimized scenario.

Naming scenarios¶

The scenario name is what you and your team see in the scenario list. Pick names that say what is in the scenario, not how it was made.

Good: Q3 revised assumptions, April observed results, Regional planning — lower costs.

Avoid: Baseline (collides with everything), Analysis Result (says nothing), New Scenario, Output, Optimized (which optimization?).

Rerunning this step creates a new version of the same scenario. The scenario list shows its current version; Version history opens previous results and their inputs. Renaming keeps that history and the workflows that consume it connected.

To make an independent experiment, choose Save future runs as… in this node's side panel, name the new scenario, then run the workflow. This works once the step has saved its first scenario. Existing consumers retain the original scenario. Different steps and different workflows always produce separate scenarios. If their names collide, the new scenario receives a suffix: a separate step also named Baseline produces Baseline (2).

The name limit leaves room for collision suffixes and historical version labels.

How it works¶

Each upstream mapping node emits a declared record type. Create Scenario passes those records through the package's routing and validation, then saves the resulting tables as a named scenario. An upstream scenario result can also be saved directly.

If a mapped input's table receives no rows while sibling tables contain data, the run reports an Mapped table empty warning on the feeding Map node. The warning names the table and sibling row counts. Check upstream joins for mismatched identifiers or display names, and check filters; confirm that the empty table is intentional before using the scenario. Tables with no mapped input do not trigger this warning.

Workflow wiring¶

Save a copy of a stored scenario under a new name:

flowchart LR
    n1["Load Scenario"] --> n2["Create Scenario (revised assumptions)"]

Keep separate named copies from the same input:

flowchart LR
    n1["Load Scenario"] --> n2["Create Scenario (first variant)"]
    n1 --> n3["Create Scenario (second variant)"]

For package-specific mapping and analysis graphs, follow the installed node's documentation. A scenario-producing node must reach Create Scenario downstream so its result is kept.

Common mistakes¶

Leaving the scenario name blank. The draft still saves, but Validate and Run identify this node and ask for its Scenario Name. Fill it in before running.
Wiring raw rows straight into Create Scenario. The canvas refuses the connection, and Validate and Run refuse a workflow that already has one, naming the edge. Put the package's mapping node for those rows between them; it decides which table each row lands in.
Ignoring a validation finding. The finding identifies the affected data and the repair guidance supplied by its owner.

Next steps¶

Load Scenario — start from an existing scenario.
Use the installed package's analysis nodes to answer questions about the saved data.

Messages this node can show¶

A run gives this node 5 minutes. A node that takes longer stops with Time limit reached.

Like every node, it can also stop on the checks before a run and the run's limits.