Portal Community

Example 1: Index a Product Catalogue Document with Mapping

Scenario: When a new product is added in the PIM system, create the index with correct field types and write the product document to Elasticsearch.

Step 1 — Create the index with explicit mappings:

{
  "Resource": "index",
  "Operation": "create",
  "IndexName": "products",
  "Mappings": {
    "properties": {
      "title":       { "type": "text", "analyzer": "english" },
      "brand":       { "type": "keyword" },
      "category":    { "type": "keyword" },
      "description": { "type": "text", "analyzer": "english" },
      "price":       { "type": "float" },
      "sku":         { "type": "keyword" },
      "tags":        { "type": "keyword" },
      "in_stock":    { "type": "boolean" },
      "created_at":  { "type": "date" }
    }
  },
  "Settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1
  }
}

Step 2 — Index the product document:

{
  "Resource": "document",
  "Operation": "create",
  "IndexName": "products",
  "DocumentId": "{{ vars.product_sku }}",
  "Fields": {
    "title":       "{{ vars.product_title }}",
    "brand":       "{{ vars.brand_name }}",
    "category":    "{{ vars.category_slug }}",
    "description": "{{ vars.product_description }}",
    "price":       "{{ vars.retail_price }}",
    "sku":         "{{ vars.product_sku }}",
    "tags":        "{{ vars.tag_array }}",
    "in_stock":    true,
    "created_at":  "{{ now() }}"
  },
  "SimplifyResponse": true
}
Expected outcome: The index is created with typed field mappings ensuring correct full-text analysis on title and description, and exact-match filtering on brand, category, and sku. The product is indexed with its SKU as the document ID for idempotent updates.

Example 2: Full-Text Search with Relevance Scoring

Scenario: A user submits a search query on an e-commerce storefront. Return the top 10 results by relevance, boosting matches in the title field.

{
  "Resource": "document",
  "Operation": "search",
  "IndexName": "products",
  "Query": {
    "query": {
      "bool": {
        "must": [
          {
            "multi_match": {
              "query":  "{{ vars.search_term }}",
              "fields": ["title^3", "description", "tags^2"],
              "type":   "best_fields",
              "fuzziness": "AUTO"
            }
          }
        ],
        "filter": [
          { "term":  { "in_stock": true } },
          { "range": { "price": { "lte": "{{ vars.max_price }}" } } }
        ]
      }
    },
    "sort": [
      { "_score": { "order": "desc" } },
      { "price":  { "order": "asc" } }
    ],
    "_source": ["title", "brand", "price", "sku", "tags"]
  },
  "Limit": 10,
  "Simplify": false
}
Expected outcome: Returns up to 10 in-stock products matching the user's query, priced within budget, sorted by relevance score then by price ascending. Title matches score 3x higher than description matches. Fuzzy matching handles minor typos. The hits array is passed to a DataMapping node to build the storefront response JSON.

Example 3: Aggregation Query for Order Analytics by Category

Scenario: A scheduled weekly report workflow queries completed orders, aggregates total revenue and order count by product category, and emails the summary to the finance team.

{
  "Resource": "document",
  "Operation": "search",
  "IndexName": "orders",
  "Query": {
    "query": {
      "bool": {
        "filter": [
          { "term":  { "status": "completed" } },
          { "range": { "completed_at": { "gte": "{{ vars.week_start }}", "lte": "{{ vars.week_end }}" } } }
        ]
      }
    },
    "aggs": {
      "revenue_by_category": {
        "terms": { "field": "category", "size": 20 },
        "aggs": {
          "total_revenue": { "sum":   { "field": "order_total" } },
          "avg_order_value": { "avg": { "field": "order_total" } }
        }
      },
      "weekly_total": {
        "sum": { "field": "order_total" }
      }
    },
    "size": 0
  }
}
Expected outcome: Returns aggregation results only (size: 0 suppresses document hits for performance). The aggregations.revenue_by_category.buckets array contains each category with its total revenue and average order value. aggregations.weekly_total.value gives the overall weekly revenue. Results are passed to a DataMapping node to build the finance report.

Example 4: Bulk Index 1000 Log Entries

Scenario: An application monitoring workflow receives a batch of 1000 log events from a webhook and indexes them all into a time-series log index efficiently using the Bulk API.

{
  "Resource": "document",
  "Operation": "create",
  "IndexName": "app-logs-{{ formatDate(now(), 'YYYY-MM') }}",
  "Bulk": true,
  "Documents": "{{ vars.log_entries_array }}",
  "SimplifyResponse": true
}

Where vars.log_entries_array is an array of objects, e.g.:

[
  {
    "timestamp":   "2026-05-23T14:32:01.123Z",
    "level":       "ERROR",
    "service":     "payment-service",
    "message":     "Connection timeout to payment gateway",
    "trace_id":    "abc123",
    "environment": "production"
  },
  {
    "timestamp":   "2026-05-23T14:32:01.456Z",
    "level":       "INFO",
    "service":     "order-service",
    "message":     "Order ORD-88421 created",
    "trace_id":    "def456",
    "environment": "production"
  }
]
Expected outcome: All 1000 log entries are indexed in a single Bulk API call, which is significantly faster than 1000 individual index requests. The index name includes the current year-month for automatic time-based partitioning. Downstream nodes check the bulk response for any partial failures.

Example 5: Update Document with Partial Fields (Upsert Pattern)

Scenario: An order fulfilment workflow updates the shipment status on an order document. If the document does not yet exist (race condition from a delayed create), upsert creates it with the available fields.

{
  "Resource": "document",
  "Operation": "update",
  "IndexName": "orders",
  "DocumentId": "{{ vars.order_id }}",
  "Fields": {
    "status":          "shipped",
    "tracking_number": "{{ vars.tracking_number }}",
    "carrier":         "{{ vars.carrier_name }}",
    "shipped_at":      "{{ now() }}",
    "estimated_delivery": "{{ vars.estimated_delivery_date }}"
  },
  "Upsert": true
}
Expected outcome: Only the five specified fields are updated on the existing order document — all other fields (customer details, line items, payment info) remain unchanged. If the document does not exist, it is created with the provided fields. The output result field will be "updated" or "created" accordingly, which can be used in a downstream Switch node to branch the workflow.