MongoDB — Examples

Example 1: Store Workflow Execution Audit Record

Scenario: At the end of every order processing workflow, insert an audit document recording the full execution context for compliance and debugging purposes.

Workflow position: Final node before Stop Workflow (or inside a Finally Block to guarantee execution).

{
  "credential_id": "mongodb-atlas-prod",
  "resource": "document",
  "operation": "insert",
  "database": "audit",
  "collection": "workflow_executions",
  "document": {
    "workflow_id": "{{ workflow.id }}",
    "workflow_name": "order-processing-v2",
    "triggered_by": "{{ vars.trigger_source }}",
    "operator_email": "{{ vars.operator_email }}",
    "started_at": "{{ workflow.started_at }}",
    "completed_at": "{{ now() }}",
    "duration_ms": "{{ vars.duration_ms }}",
    "input_order_id": "{{ vars.order_id }}",
    "outcome_status": "{{ vars.final_status }}",
    "outcome_message": "{{ vars.outcome_message }}",
    "steps_executed": "{{ vars.steps_executed }}",
    "environment": "{{ env.DEPLOY_ENV }}"
  }
}

Expected outcome: A complete audit document is persisted in MongoDB. The inserted _id is available as $node.InsertAuditRecord.output.inserted_id and can be included in success notifications for traceability.

Example 2: Query Customer Profile for Personalisation

Scenario: At the start of an email campaign workflow, retrieve the customer profile to personalise the message — including their tier, preferences, and last purchase.

Workflow position: Early in the workflow, after receiving the customer ID from a trigger or form input.

{
  "credential_id": "mongodb-atlas-prod",
  "resource": "document",
  "operation": "find",
  "database": "crm",
  "collection": "customers",
  "filter": {
    "customer_id": "{{ vars.customer_id }}",
    "status": "active"
  },
  "projection": {
    "customer_id": 1,
    "full_name": 1,
    "email": 1,
    "tier": 1,
    "preferences": 1,
    "last_purchase_date": 1,
    "total_spend_ytd": 1,
    "_id": 0
  },
  "limit": 1
}

Expected outcome: The customer document is returned. A downstream If Condition node checks $node.GetCustomer.output.count == 0 to handle unknown customers. The tier and preferences fields drive personalised content in the Email SMTP node.

Example 3: Atomic Order Status Transition

Scenario: When a payment confirmation webhook fires, atomically transition the order from "pending_payment" to "confirmed" and return the updated document to trigger fulfilment.

Workflow position: Webhook Trigger → Validate Payment → MongoDB find-one-and-update → Route to fulfilment workflow.

{
  "credential_id": "mongodb-atlas-prod",
  "resource": "document",
  "operation": "find-one-and-update",
  "database": "ecommerce",
  "collection": "orders",
  "filter": {
    "order_id": "{{ vars.order_id }}",
    "status": "pending_payment"
  },
  "update": {
    "$set": {
      "status": "confirmed",
      "payment_confirmed_at": "{{ now() }}",
      "payment_reference": "{{ vars.payment_reference }}",
      "updated_at": "{{ now() }}"
    },
    "$push": {
      "status_history": {
        "from_status": "pending_payment",
        "to_status": "confirmed",
        "changed_at": "{{ now() }}",
        "trigger": "payment_webhook",
        "payment_ref": "{{ vars.payment_reference }}"
      }
    }
  },
  "return_document": "after",
  "upsert": false
}

Expected outcome: The order document is updated atomically and the post-update state is returned. $node.ConfirmOrder.output.found is false if the order was already confirmed (duplicate webhook) — use an If Condition to handle idempotently. The updated document drives the Sub-Workflow trigger for fulfilment.

Example 4: Daily Revenue Aggregation for Reporting

Scenario: A scheduled workflow runs every morning. Aggregate the previous day's completed orders by product category and write a summary document for the BI dashboard.

Workflow position: Scheduled Trigger → Variable Assignment (set date range) → MongoDB aggregate → Insert summary → Email report.

{
  "credential_id": "mongodb-atlas-prod",
  "resource": "document",
  "operation": "aggregate",
  "database": "ecommerce",
  "collection": "orders",
  "pipeline": [
    {
      "$match": {
        "status": "completed",
        "completed_at": {
          "$gte": "{{ vars.report_date_start }}",
          "$lt": "{{ vars.report_date_end }}"
        }
      }
    },
    { "$unwind": "$line_items" },
    {
      "$group": {
        "_id": {
          "category": "$line_items.category",
          "region": "$shipping_region"
        },
        "revenue": { "$sum": "$line_items.subtotal" },
        "units_sold": { "$sum": "$line_items.quantity" },
        "order_count": { "$sum": 1 },
        "avg_item_value": { "$avg": "$line_items.unit_price" }
      }
    },
    { "$sort": { "revenue": -1 } },
    {
      "$project": {
        "_id": 0,
        "category": "$_id.category",
        "region": "$_id.region",
        "revenue": 1,
        "units_sold": 1,
        "order_count": 1,
        "avg_item_value": { "$round": ["$avg_item_value", 2] }
      }
    }
  ]
}

Expected outcome: $node.DailyRevenueAgg.output.results contains the category-by-region breakdown array. A downstream insert node writes this array as a summary document to the daily_reports collection. The Email SMTP node formats the top 5 categories as an HTML table for the morning report.

Example 5: Atlas Full-Text Product Search

Scenario: A customer-facing search workflow receives a search term and returns the top 10 matching product documents ranked by relevance score.

Workflow position: HTTP Request Trigger → MongoDB aggregate (Atlas $search) → HTTP Response with results.

{
  "credential_id": "mongodb-atlas-prod",
  "resource": "document",
  "operation": "aggregate",
  "database": "catalogue",
  "collection": "products",
  "pipeline": [
    {
      "$search": {
        "index": "product_search",
        "compound": {
          "must": [
            {
              "text": {
                "query": "{{ vars.search_query }}",
                "path": ["name", "description", "tags"],
                "fuzzy": { "maxEdits": 1 }
              }
            }
          ],
          "should": [
            {
              "text": {
                "query": "{{ vars.search_query }}",
                "path": "name",
                "score": { "boost": { "value": 3 } }
              }
            }
          ],
          "filter": [
            { "equals": { "path": "in_stock", "value": true } }
          ]
        }
      }
    },
    {
      "$project": {
        "product_id": 1,
        "name": 1,
        "price": 1,
        "category": 1,
        "thumbnail_url": 1,
        "score": { "$meta": "searchScore" },
        "_id": 0
      }
    },
    { "$sort": { "score": -1 } },
    { "$limit": 10 }
  ]
}

Expected outcome: Up to 10 in-stock products are returned ranked by full-text relevance. Name matches are boosted 3x over description matches. Fuzzy matching handles minor typos. The results array is returned directly as the HTTP response body.

Example 6: Inventory Decrement with Low-Stock Alert

Scenario: When an order is placed, decrement the stock count for each ordered SKU atomically. If any SKU falls below the reorder threshold, trigger a procurement notification workflow.

Workflow position: Inside a Loop node iterating over order line items.

// Step 1 — Decrement stock count atomically
{
  "credential_id": "mongodb-atlas-prod",
  "resource": "document",
  "operation": "find-one-and-update",
  "database": "inventory",
  "collection": "stock_levels",
  "filter": {
    "sku": "{{ vars.current_sku }}",
    "quantity_available": { "$gte": "{{ vars.ordered_quantity }}" }
  },
  "update": {
    "$inc": { "quantity_available": "{{ vars.ordered_quantity * -1 }}" },
    "$set": {
      "last_decremented_at": "{{ now() }}",
      "last_order_id": "{{ vars.order_id }}"
    }
  },
  "return_document": "after",
  "upsert": false
}

// Step 2 — Check threshold (If Condition node after Step 1):
// Condition: $node.DecrementStock.output.document.quantity_available <= $node.DecrementStock.output.document.reorder_threshold
// True branch: Sub-Workflow trigger → procurement notification

// Step 3 — Handle insufficient stock (false = filter found no document with enough stock)
// If $node.DecrementStock.output.found == false: Stop Workflow with status=failed, message="Insufficient stock for SKU {{ vars.current_sku }}"

Expected outcome: Stock is decremented atomically — no race conditions. If insufficient stock exists, the operation does not decrement and returns found: false for clean error handling. When remaining stock falls to the reorder threshold, a Sub-Workflow triggers an automated purchase order creation workflow.