Importing from CSV ​

The same three-step wizard imports three different things, depending on where you open it:

The wizard guides you through the same three steps either way: Upload, Map columns, and Results — only the column set and what a row builds differ.

An S7 or OPC UA data source's detail page also offers Export, the counterpart of its Import action: a CSV of every data point the source has declared, in the same column set. See Exporting data points below.

The monitor list's own Create dropdown offers the same pairing for CVE monitors: Export CSV downloads every CVE monitor in the organization, in the same column set its Import CSV reads. See Exporting CVE monitors below.

Export and import together are a loop, not a one-way trip — see Keeping a sheet in sync below.

Importing CVE monitors ​

Organization administrators can create many CVE monitors at once from a CSV file. In the monitor list, open the Create dropdown and choose Import CSV to open the import wizard.

CVE monitors are the only monitor type this import creates. Connections to OPC UA servers and S7 PLCs are added as data sources, and everything that alerts on a value is a condition monitor — neither is a row in a spreadsheet. To declare S7 tags or OPC UA nodes in bulk, see Importing S7 data points or Importing OPC UA data points.

Two values behave in ways worth knowing up front:

  • escalationPolicy references an existing escalation policy by name, or by the id its own page's URL ends in — /app/escalation-policies/JgaEBgzn is the policy JgaEBgzn. A name must match exactly, so create the policy before importing. A plain number is read as a name and nothing else: a file that names the policy as 7 fails that row rather than resolving a row number.
  • incidentMessageTemplate is the literal incident message, not a reference to a saved template.

The column set is listed under Map columns.

Importing S7 data points ​

Organization administrators can declare many S7 data points at once from a CSV of tag addresses. Open an S7 data source's detail page and choose Import to open the wizard, already bound to that source.

Because the source is implied by where you started the import, the file is about tags and nothing else — no endpoint, rack or slot column, and no monitorType either. The column set is listed under Map columns.

A data point this import declares is adopted and reads on the source's own cadence, like any other data point of the source. A row naming an address and data type already declared on the source is a no-op — it resolves to the existing data point rather than creating a duplicate, so re-running an unchanged file is harmless.

Unlike the CVE import, this run is all or nothing: every row is checked before anything is written, and if any row fails, nothing is created — the results step lists every failing row so you can fix the file and try again. See Results.

Alerting on the values you import ​

Mapping four more columns — aggregation, operation, operand and duration — turns each row from a data point declaration into a threshold alert on it: "alert when the average of DB1.DBD10 over 5 minutes is above 80". For a row with all four mapped, the import creates:

  • a condition — the graph Sensor → Aggregate → Compare → Alert — pinned to the data point the row declares, and
  • a condition monitor that alerts on it, in the Conditions group of the monitor list.

The condition opens in the same guided sentence form a hand-built threshold uses, so a hundred imported alerts stay editable afterwards — nothing about them is canvas-only.

Once any of the four is mapped, all four must be mapped, along with name (the condition and monitor's name) and escalationPolicy (who an incident from it pages) — a row cannot build a threshold from three fields and a guess at the fourth. Leaving all four unmapped keeps the plain behavior above: rows declare data points only, with no conditions or monitors created.

With the columns mapped, each row still decides for itself whether it carries a threshold. A row that fills in all six of name, escalationPolicy, aggregation, operation, operand and duration creates one. A row that leaves all six empty declares only its data point, so one file can mix data points with and without a threshold — which is what exporting a source writes. A row that fills in some of them but not all fails, and its error names the ones it is missing. A field set with Fixed value… counts as filled in on every row, so it does not stop a row whose other threshold cells are empty from declaring only its data point.

Condition names are unique per organization and case-insensitive. A row whose name is already taken — by an existing condition, or by another row in the same file — fails validation before anything is written, the same way an invalid address does, unless Update existing monitors is on and the match is pinned to this row's own data point, which updates the condition instead.

The Activate created monitors toggle on the mapping step decides whether the monitors this run creates start active or inactive. Off (the default) creates them inactive: they sit in the monitor list for review, and the evaluator skips an inactive monitor entirely, so none of them can raise an incident until you turn them on by hand. On starts them alerting immediately. This is a good default for a first import of a hundred thresholds — review the generated conditions, then activate the ones that look right.

Importing OPC UA data points ​

Organization administrators can declare many OPC UA data points at once from a CSV of node ids — the same case a machine builder's node list or a large server you'd rather not browse covers. Open an OPC UA data source's detail page and choose Import to open the wizard, already bound to that source.

Because the source is implied by where you started the import, the file is about nodes and nothing else: a row is one column, nodeId. Unlike an S7 tag, an OPC UA data point's value type is not declared — it is learned from the first reading, the same as when you declare one by hand — so there is no dataType column to map. The column set is listed under Map columns.

Node ids are checked for valid syntax only — ns=2;s=Line1.Temperature or ns=3;i=1001, the same textual form the source detail page uses. Whether the node actually exists on the server is not checked at import time: that would make the import depend on a reachable server, which defeats the point of preparing a file before commissioning. A node id the server does not recognize comes back as a bad reading once the source starts sampling it, visible on the source's detail page like any other bad reading.

A row naming the source's own health-check node is refused, the same way declaring it by hand is — the point already exists as the source's reachability probe, so importing it again would create a second, meaningless liveness point rather than a real reading.

A data point this import declares is adopted and reads on the source's own cadence, like any other data point of the source. A row naming a node already declared on the source is a no-op — it resolves to the existing data point rather than creating a duplicate, so re-running an unchanged file is harmless, and two rows that spell the same node differently (say, with or without a leading zero in the identifier) still resolve to one data point.

Unlike the CVE import, this run is all or nothing: every row is checked before anything is written, and if any row fails, nothing is created — the results step lists every failing row so you can fix the file and try again. See Results.

Alerting on the values you import ​

Mapping four more columns — aggregation, operation, operand and duration — turns each row from a data point declaration into a threshold alert on it: "alert when the average of ns=3;s=Boiler.Pressure over 5 minutes is above 80". For a row with all four mapped, the import creates:

  • a condition — the graph Sensor → Aggregate → Compare → Alert — pinned to the data point the row declares, and
  • a condition monitor that alerts on it, in the Conditions group of the monitor list.

The condition opens in the same guided sentence form a hand-built threshold uses, so a hundred imported alerts stay editable afterwards — nothing about them is canvas-only. Because an OPC UA data point's value type is only learned from its first reading, a threshold over a freshly declared node imports and validates cleanly even if the node turns out to hold, say, a boolean — it simply won't fire sensibly under a numeric comparison like avg ... > 80.

Once any of the four is mapped, all four must be mapped, along with name (the condition and monitor's name) and escalationPolicy (who an incident from it pages) — a row cannot build a threshold from three fields and a guess at the fourth. Leaving all four unmapped keeps the plain behavior above: rows declare data points only, with no conditions or monitors created.

With the columns mapped, each row still decides for itself whether it carries a threshold. A row that fills in all six of name, escalationPolicy, aggregation, operation, operand and duration creates one. A row that leaves all six empty declares only its data point, so one file can mix data points with and without a threshold — which is what exporting a source writes. A row that fills in some of them but not all fails, and its error names the ones it is missing. A field set with Fixed value… counts as filled in on every row, so it does not stop a row whose other threshold cells are empty from declaring only its data point.

Condition names are unique per organization and case-insensitive. A row whose name is already taken — by an existing condition, or by another row in the same file — fails validation before anything is written, the same way an invalid node id does, unless Update existing monitors is on and the match is pinned to this row's own data point, which updates the condition instead.

The Activate created monitors toggle on the mapping step decides whether the monitors this run creates start active or inactive. Off (the default) creates them inactive: they sit in the monitor list for review, and the evaluator skips an inactive monitor entirely, so none of them can raise an incident until you turn them on by hand. On starts them alerting immediately. This is a good default for a first import of a hundred thresholds — review the generated conditions, then activate the ones that look right.

Updating existing rows on re-import ​

By default, a row whose name matches something that already exists fails — "Monitor name already exists" on the CVE import, "Condition name already exists" on an S7 or OPC UA import — nothing about a plain import changes something you already have. To maintain a device sheet or a tag list over time and re-import it as things change, turn on Update existing monitors on the mapping step (off by default, for every mode).

On the CVE import, a row whose name matches an existing CVE monitor updates that monitor's vendor, orderCode, product, firmware and escalationPolicy instead of failing — tags and the source data source are left exactly as they were: a tags value on the row is ignored for an update (see Assigning tags), and the source data source is never set by this import at all, on a create or an update. A row whose name matches a monitor of a different type (say, a heartbeat monitor) is still a row error: there is nothing for a CVE row to update on a monitor of another kind, so nothing is written for that row.

On an S7 or OPC UA import with a row's four threshold columns mapped (see Alerting on the values you import or the equivalent OPC UA section), a row whose name matches an existing condition that is already pinned to exactly the data point the row declares — the same address or node id — updates that condition's aggregation, operation, operand and duration, and the monitor's escalationPolicy, instead of failing. The monitor's active state and its tags are left exactly as they were, the same way the CVE import leaves a CVE monitor's tags and source data source alone. A row whose name matches a condition pinned to a different data point — the name was reused for a different tag, say — is still a row error, and because an S7 or OPC UA run is all-or-nothing, nothing in the file is written: there is nothing safe to update when the row and the existing condition disagree about what they are even alerting on.

A row whose name matches nothing yet still creates, on or off.

The results step reports these updated rows separately from newly created ones — see Results.

Exporting CVE monitors ​

From the monitor list, open the Create dropdown and choose Export CSV to download every CVE monitor in the organization, in the same column set Importing CVE monitors reads: monitorType, name, vendor, orderCode, product, firmware, escalationPolicy, incidentMessageTemplate and tags. escalationPolicy is written by name and tags \|-separated, the same forms Map columns reads back. incidentMessageTemplate is always empty — no CVE monitor carries one, so there is nothing to write there.

The export respects the list's active filters — status, escalation policy, data source, tags, and search, plus the stale/muted toggles — except the monitor type filter, since this action only ever exports CVE monitors regardless of what the list is otherwise showing.

Re-importing the file, with Update existing monitors turned on, is a no-op: every row matches its own monitor by name, so the results step reports every row updated rather than created.

Exporting requires the same organization administrator permission as importing.

Exporting data points ​

On an S7 or OPC UA data source's detail page, Export downloads a CSV of every data point the source has declared, in the same column set its own Import action reads — address/dataType (S7) or nodeId (OPC UA), plus name, escalationPolicy, aggregation, operation, operand, duration and tags for a data point that has exactly one threshold condition pinned to it. A data point with no threshold leaves those columns empty; one with more than one threshold is exported once per threshold, as separate rows sharing the same address or node id. escalationPolicy is written by name, duration in seconds, operation as gt/gte/lt/lte/eq/neq, and tags \|-separated — the same forms Map columns reads back.

Re-importing the file against the same source, with Update existing monitors turned on, is a no-op: every row matches its own data point and its own condition (where it has one), so the results step reports every row updated or unchanged rather than created.

Exporting requires the same organization administrator permission as importing.

Keeping a sheet in sync ​

Export writes the exact column set import reads, so the two are a loop, not a one-way trip: export a source's data points or the monitor list's CVE monitors, edit the file in a spreadsheet, and re-import it with Update existing monitors turned on. Because the exported header names match the import's own field names, the mapping step re-detects every column automatically on the way back in — there is nothing to remap by hand, even for the threshold columns.

This is how you maintain a device sheet or a monitor list outside Pulse over time: change an operand, rename an escalation policy, add a firmware version, then re-import the edited file. A row whose name (or address/node id, for a data point) hasn't changed updates the thing it already matches instead of failing on the collision; a new row added to the sheet still creates, same as any other import.

Assigning tags ​

An optional tags column assigns existing tags to a monitor this import creates: |-separated tag names, each trimmed of surrounding whitespace (for example Line 1|Boiler). Every name must match an existing tag exactly (case-insensitively) — importing never creates a tag, so a name that matches none is a row error on a CVE row that creates a monitor, or fails the whole run on an S7 or OPC UA row that creates a condition monitor, the same as any other column those imports cannot resolve. A row that updates an existing monitor or condition ignores its tags cell, so an unknown name there is not an error. See Step 3 — Results for what that means for what gets written.

A tag name that itself contains a | cannot round-trip through this column: both the export and the |-splitting on import treat every | as a separator, with no escaping for one inside a name. Avoid a | in a tag's own name if you plan to export and re-import it.

On an S7 or OPC UA import, tags only has a monitor to attach to on a row that also maps the four threshold columns and creates a condition monitor — see Alerting on the values you import (S7) or the equivalent OPC UA section. On a plain data-point row, the column is read but ignored, since nothing is created that could carry a tag.

CSV format ​

The first row must be a header row of column names — the next step matches those names to fields (you can adjust the mapping by hand). Save the file as UTF-8.

The import accepts a comma, semicolon, or tab as the separator — whichever one appears most often in the header row is used for the whole file, so you don't need to pick one yourself. A leading UTF-8 byte-order mark, which some locales' Excel adds automatically, is stripped before reading the file. Together, this means a semicolon-separated, BOM-prefixed export — the default a German-language Excel produces — imports exactly like a plain comma-separated one. Otherwise the file follows standard CSV rules (RFC 4180): wrap any value that itself contains the separator, a quote, or a newline in double quotes, doubling up any quote inside it.

To start from a working example, use Download example CSV on the upload step: it contains the columns for the wizard you opened, with one or more example rows.

Step 1 — Upload ​

Drag a CSV file onto the drop zone, or click to browse. A preview table shows the first rows so you can confirm the file was read correctly; use Replace to swap in a different file. Click Next to continue, or Cancel to close the wizard.

Step 2 — Map columns ​

Map each field to a column from your CSV. The wizard auto-detects matching column names and pre-fills the mapping where it can. For every field you can:

  • pick the CSV column whose values to use,
  • choose Fixed value… to apply one value to every row (handy for shared settings such as the escalation policy), or
  • leave it Not mapped — allowed only for optional fields.

The table lists every column, whether it is required, and the values it accepts.

CVE monitor columns ​

ColumnRequiredValid values / format
monitorTypeYescve
nameYesFree text
vendorYesDevice vendor, e.g. Siemens
orderCodeOne ofDevice order code / MLFB, e.g. 6ES7516-3AN00-0AB0 — a row needs this or product
productOne ofProduct / module type name as the vendor's advisories spell it, e.g. AC500 V3
firmwareOptionalFirmware version, e.g. V2.9.2 (empty → matches all firmware versions)
escalationPolicyYesName (exact match) or the id from the policy's URL
incidentMessageTemplateOptionalFree text (the message itself)
tagsOptionalExisting tag names, |-separated, e.g. Line 1|Boiler — see Assigning tags

TIP

CVE monitors match published advisories against a device by vendor + orderCode and/or product (+ optional firmware). See CVE monitors for how matching works.

S7 data point columns ​

ColumnRequiredValid values / format
addressYesAn S7 address, e.g. DB1.DBW0 or DB2.DBD4
dataTypeYesBOOL, BYTE, WORD, DWORD, INT, DINT, or REAL
nameOnly if any threshold column is mappedWhat to call the condition and its monitor
escalationPolicyOnly if any threshold column is mappedName (exact match) or the id from the policy's URL
aggregationAll four, or none (see below)min, max, sum, avg (or average), count
operationAll four, or nonegt (or >, above), gte (>=), lt (<, below), lte (<=), eq (=), neq (!=)
operandAll four, or noneThe threshold value, e.g. 80 or 80,5 (a decimal comma is also read as the decimal separator)
durationAll four, or noneThe aggregation window: seconds, or a number with a unit, e.g. 300, 5m, 1h (2,5m also works)
tagsOptionalExisting tag names, |-separated — ignored unless the row also creates a condition monitor (see Assigning tags)

TIP

See S7 data sources for what each address form and data type means, and Alerting on the values you import for the four threshold columns.

OPC UA data point columns ​

ColumnRequiredValid values / format
nodeIdYesAn OPC UA node id, e.g. ns=2;s=Line1.Temperature or ns=3;i=1001
nameOnly if any threshold column is mappedWhat to call the condition and its monitor
escalationPolicyOnly if any threshold column is mappedName (exact match) or the id from the policy's URL
aggregationAll four, or none (see below)min, max, sum, avg (or average), count
operationAll four, or nonegt (or >, above), gte (>=), lt (<, below), lte (<=), eq (=), neq (!=)
operandAll four, or noneThe threshold value, e.g. 80 or 80,5 (a decimal comma is also read as the decimal separator)
durationAll four, or noneThe aggregation window: seconds, or a number with a unit, e.g. 300, 5m, 1h (2,5m also works)
tagsOptionalExisting tag names, |-separated — ignored unless the row also creates a condition monitor (see Assigning tags)

TIP

See OPC UA data sources for the node id syntax and how a data point's value type is learned, and Alerting on the values you import for the four threshold columns.

When every required field is mapped, click Run Import. To close and discard your work, click Cancel; to pause without losing your column mappings, use the × button in the header — the wizard resumes where you left off when you reopen it.

Step 3 — Results ​

A summary shows how many rows were imported successfully and how many failed. With Update existing monitors on, it also shows how many rows updated an existing CVE monitor or condition instead of creating one.

  • CVE monitors commit row by row, so a failed row does not stop the rows around it from being created or updated.
  • S7 and OPC UA data points (and the conditions a threshold row creates or updates) commit all together: if any row failed, the summary shows zero successes and zero updates, and nothing was written.

Each failed row is listed with the error that caused it. Click Download failed rows to export just those rows as a CSV, correct them, and import the file again.