Skip to content

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 Scenario Shown in the scenario list. The panel marks it required, but a workflow with it left blank saves, validates and runs. The scenario is then called Scenario. Use descriptive, outcome-oriented names. At most 200 characters. A longer name is reported on the node when the workflow is saved and refused before the 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 today First day of the planning window the scenario is about.
Horizon End today + 1 year Last day of that window. Must not fall before Horizon Start.
Currency EUR ISO 4217 base currency for the scenario's monetary values.

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?).

You can reuse a name. A name the project already holds gets a suffix rather than a duplicate. Run the same workflow three times and the scenario list shows Baseline, Baseline (2) and Baseline (3): three distinct entries, told apart by a number and nothing else. Be specific up front.

The 200-character limit leaves room for that suffix. The name is stored as you wrote it, and the run adds the (2) after it.

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 empty_mapped_table 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 run uses Scenario, then Scenario (2) on a repeat. Choose a descriptive name.
  • Wiring raw rows straight into Create Scenario. Use the package's mapping nodes to supply declared record types.
  • 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.