Guide
Import Model Data
When limits, scenarios, or model tables already exist in a spreadsheet, they can be imported rather than entered by hand, and re-imported as the source changes without discarding the work done in the model between updates.
Where to start
On the Constraints screen, open Import or update data, then choose what is being brought in:
| Path | What it covers |
|---|---|
| Update limits and capacities | Budgets, requirements, and resource limits. The most common import. |
| Add scenarios | Scenario assumptions, outages, and changed rates. |
| Advanced model tables | Resources, flows, conversions, decision groups, decision options, scenario values, and uncertainty values. |
CSV, TSV, and XLSX are accepted. For a workbook with several sheets, the sheet is chosen after the file loads. Download template provides a CSV with the correct header row for the selected table.
The staging flow
The active model is unchanged until the final step. Everything before it is preview.
The file is parsed in the browser. Spreadsheet parsing loads only when the importer is opened, so it costs nothing when unused.
A mapping is suggested from your headers, with a count of the required fields matched. Required fields and populated optional columns are shown, while unused optional mappings stay collapsed. A saved mapping from a previous import can be reused.
A preview of the parsed rows, so a shifted column or stray header is visible before validation.
Values, references to existing model entities, and source ownership are checked. The full structural model validator runs as well, so an import cannot leave the model in an invalid state.
Added, changed, and removed records. Changed rows show field-level before and after values rather than internal IDs.
The active model changes at this point, atomically.
Updating an existing record changes only the fields the file mapped. Operational settings the import did not own, such as scenario overrides, schedules, and cost curves, are left in place.
Import source ID
The Import source ID field is optional. It gives a feed a stable name, such as finance-budget-feed. Reusing the same ID identifies a later import as the same source updating its own rows.
Left blank, the entity type, filename, and sheet name identify the source instead. That works, but filenames and sheet names change over time, so a stable source ID is recommended for anything intended to be re-imported.
Re-importing is reversible
An import is an overlay rather than a replacement. SSPLAX retains the state each record held before a source changed it, so when a row is absent from a later version of the file:
| The record was | What happens |
|---|---|
| Created by this source | Removed. |
| Already present, then overlaid by this source | Restored to its pre-import state. |
| Never touched by this source | Left unchanged. |
This applies to constraints and schedules, resources, flows, conversions, decision groups, decision options, scenarios, and uncertainty values, and it survives saving and reopening the workspace. Manual edits to unrelated records are never affected.
Importing an empty file from a known source is well defined. Everything that source created is removed, and everything it overlaid returns to its prior state. This is a clean way to withdraw a feed.
One record, one owner
A record managed by one import source cannot be silently overwritten by another. When two feeds claim the same row, the import is blocked with a conflict rather than resolved in favor of whichever ran last.
Scenarios are owned at the scenario level rather than per override, because a scenario's name, description, probability, and weight are shared by everything within it. A second source cannot bypass ownership by importing a different override into an existing scenario.
Size limits
Enforced before and after parsing, so an oversized file fails early:
| Limit | Maximum |
|---|---|
| File size | 10 MB |
| Data rows | 10,000 |
| Columns | 200 |
| Characters in one cell | 50,000 |
Two parsing rules are worth knowing. A scenario value stays scalar when no period column is mapped. A period list is rejected in full if any token is blank or non-numeric, since a silently shortened series would produce a model that looks correct but is not.
Provenance
A confirmed import records a content hash of the source file, the mapping used, the source identity, the records and scenarios it touched, the timestamp, and the pre-import snapshot it can restore from. That record persists with the workspace and appears in exports, so a later reviewer can tell which values were entered directly and which arrived from a feed.
For the wider question of documenting where numbers come from, see Assumptions & Validation.