CollectionOperation NodeTypeCode: collection-operation

The Standard Node Data Envelope

Every node's input and output — CollectionOperation included — travels inside the same standard envelope. Run metadata sits at the top level; the real payload lives under items, each entry wrapping its record in "json":

{
  "timestamp": "2026-07-24T01:02:27.8652562Z",
  "triggerTime": "2026-07-24T01:02:27.8652562Z",
  "resource": "trigger",
  "operation": "manual-trigger",
  "status": "success",
  "portName": "main",
  "items": [
    {
      "json": {
        "timestamp": "2026-07-24T01:02:27.8652562Z",
        "triggerTime": "2026-07-24T01:02:27.8652562Z",
        "resource": "trigger",
        "operation": "manual-trigger",
        "status": "success",
        "portName": "main"
      }
    }
  ],
  "success": true
}

CollectionOperation resolves the collection to operate on from InputData["items"] by default, unwrapping each entry's "json" value into one element — the same shared ResolveSourceRecords/ExtractRecordsFromItems helper DataMapping uses.

When to Use

• Filter orders by status: An upstream node returns all orders for a customer. Use filter with item.status === "active" to keep only the orders that need processing — no CodeExecute required.
• Map records to extract just IDs: A database query returns full order objects. Use map with expression item.orderId to produce a clean array of order IDs for a bulk-cancel API call.
• Sum or fold a collection to one value: Use reduce with acc + item.total and initialValue: 0 to total up line-item amounts.
• Sort records by a field: A queue of pending approvals needs to be processed oldest-first. Use sort with field: "createdAt" and direction: "asc".
• Get distinct values of a field: An event log contains multiple entries per region. Use distinct with field: "region" to get a unique list of affected regions for targeted notifications.
• Tolerate bad records instead of failing the whole batch: A collection with a handful of malformed items (a missing field, an unparsable value) shouldn't abort processing of the rest. The default onError: "continue" behavior skips only the failing items and reports them in errorRecords/errorCount — the node still succeeds.

Configuration

Operations Reference

Error Handling: Per-Item Failures Don't Abort the Batch

filter, map, and reduce evaluate a JS expression once per item. A single bad item — a thrown expression error, or a NaN arithmetic result — never aborts the whole operation. It's recorded as a failure in errorRecords/errorCount, and processing continues with the next item.

Even in onError: "continue" mode, the failed items are not silently dropped from the record — each one appears in errorRecords as {"item": <original item>, "error": "<message>"}, capped at maxErrorsToCollect entries (or unlimited if it's 0) even though errorCount keeps counting every failure beyond that cap.

Output Ports

Output Fields

Sample Configurations

Filter — only active orders, tolerate bad records

{
  "nodeType": "collection-operation",
  "settings": {
    "operation": "filter",
    "expression": "item.status === \"active\"",
    "onError": "continue",
    "maxErrorsToCollect": 10
  }
}

Map — extract order IDs only

{
  "nodeType": "collection-operation",
  "settings": {
    "operation": "map",
    "expression": "item.orderId"
  }
}

Reduce — sum all line item amounts

{
  "nodeType": "collection-operation",
  "settings": {
    "operation": "reduce",
    "expression": "acc + item.amount",
    "initialValue": "0"
  }
}

Sort — newest records first

{
  "nodeType": "collection-operation",
  "settings": {
    "operation": "sort",
    "field": "createdAt",
    "direction": "desc"
  }
}

Sample Output — filter with partial errors

{
  "status": "success",
  "successCount": 2,
  "errorCount": 1,
  "errorRecords": [
    { "item": { "id": "item_003", "status": null }, "error": "Cannot read properties of null (reading 'toLowerCase')" }
  ],
  "count": 2,
  "items": [
    { "json": { "id": "item_001", "status": "active" } },
    { "json": { "id": "item_002", "status": "active" } }
  ]
}

Expression Reference

Node Policies & GuardRails

Pattern Examples

See Examples for elaborate, realistic worked examples including error-handling behavior and inlineDataSource usage.

Pattern 1 — Filter Active Subscriptions, Then Extract Emails for Bulk Send

// Node 1: CollectionOperation — filter active premium subscriptions
{ "operation": "filter", "expression": "item.status === \"active\" && item.tier === \"premium\"" }
// items: premium active subscription records only

// Node 2: CollectionOperation — extract customer email addresses
{ "operation": "map", "expression": "item.customerEmail" }
// items: one item per email string, ready for bulk email send

Pattern 2 — Sum Invoice Totals and Get Distinct Regions

// Node 1: Sum all invoice amounts
{ "operation": "reduce", "expression": "acc + item.totalAmount", "initialValue": "0" }

// Node 2: Get distinct billing regions from the same invoices
{ "operation": "distinct", "field": "billingRegion" }
// items: ["EMEA", "APAC", "AMER"] (unique regions only), one item per region