How to Build a Real-Time Order Dashboard with Multiple Data Sources

Create a centralized order tracking dashboard combining data from multiple platforms.

What This Integration Does

Multi-channel sellers usually have orders flowing into Shopify, WooCommerce, and sometimes a B2B platform like BigCommerce, plus a back office in NetSuite. Each platform has its own admin UI, its own report exports, and its own order ID format. Operations spends real time stitching screens together to answer simple questions like "how many orders are stuck in fulfillment today". This workflow aggregates every channel's recent orders into a single store (MongoDB) on a schedule, and an optional dashboard sink (Monday.com or a BI tool) picks it up from there.

The workflow runs on a 5-15 minute schedule, fans out to each channel in parallel, normalizes the shape of every order to a single schema, and upserts by a composite key (channel + native order id) so re-running is safe. Dashboards read from the consolidated MongoDB collection and never have to talk to the source systems directly.

Prerequisites

  • One or more e-commerce connections: Shopify, WooCommerce, BigCommerce.
  • A MongoDB connection with write access to a target database (e.g. order_dashboard).
  • Optional: a Slack connection for anomaly alerts, and a Monday.com or BI tool that reads from MongoDB.

Step 1: Schedule Trigger

Drop a Trigger node and set it to Schedule every 15 minutes. The previous run's timestamp is exposed on the trigger so each run can fetch only orders updated since the last pull.

Step 2: Parallel Fetch from Every Channel

Add a Parallel node with one branch per channel. Each branch has a Connector node:

  • shopify list-orders with updated_at_min = {{ lastRunAt }}
  • woocommerce list-orders with after = {{ lastRunAt }}
  • bigcommerce list-orders with min_date_modified = {{ lastRunAt }}

Page through each result set until empty. Each branch returns a list of orders in that platform's native shape.

Step 3: Transform to a Common Schema

Add a Transform node per branch to project every order down to the same shape:

{
  "_id": "{{ channel }}-{{ nativeOrderId }}",
  "channel": "shopify",
  "nativeOrderId": "1001",
  "orderNumber": "#1001",
  "customer": { "name": "...", "email": "..." },
  "total": 129.50,
  "currency": "USD",
  "status": "paid",
  "fulfillmentStatus": "unfulfilled",
  "placedAt": "2025-01-30T12:00:00Z",
  "updatedAt": "2025-01-30T13:00:00Z",
  "lineItems": [ ... ]
}

The _id composite key is critical: it makes the next step idempotent across channels.

Step 4: AI Anomaly Flagging (Optional)

Add a Connector node in Agent Mode with Structured Output per order to flag unusual ones: high value, bulk quantity, mismatched billing / shipping address, or first-time customer with overnight shipping. Return { "flag": "review_required" | "ok", "reason": "string" } and merge it into the document.

Step 5: Upsert to MongoDB

Add a Loop over the combined order list and a Connector node calling mongodb update-documents:

  • Database: order_dashboard
  • Collection: orders
  • Filter: { "_id": "{{ order._id }}" }
  • Update: { "$set": {{ order }} }
  • Upsert: true

Step 6: Alert and Surface

After the loop, count orders flagged as review_required and, if any, send a slack send-message to your operations channel with the order numbers and reasons. Your dashboard tool (Monday.com, Metabase, Grafana) reads from the orders collection and renders the rest.

Tips

  • Index updatedAt, channel, and fulfillmentStatus in MongoDB. Dashboards filter on these constantly.
  • Keep the 15-minute schedule generous on the first run by setting lastRunAt back a few days to backfill, then let the workflow run incrementally.
  • If a channel goes down, the Parallel branches are independent so the rest still upsert. Don't bail the whole run on one channel's failure.
  • Store the original native payload as a sub-document raw so you never have to re-fetch when adding a new field to the schema.

Common Pitfalls

  • Native order ID collisions across channels. Shopify and WooCommerce both start at 1001. Always prefix _id with the channel name.
  • Timezone handling. Each platform uses a different timezone for filters. Convert lastRunAt to each store's timezone before sending it as a filter, or use UTC ISO strings everywhere if the API supports it.
  • Pagination silently truncates. list-orders defaults to 50 results. Loop until the API returns fewer than the page size.
  • Schema drift. When Shopify adds a new field, the Transform step silently drops it unless you update the mapping. Periodically diff raw against the normalized schema.

Testing

Run manually with lastRunAt set to the start of today. Confirm orders from each channel land in MongoDB with the expected _id prefix. Open the BI tool or Monday.com board and confirm the dashboard renders. Then enable the schedule.

Learn More

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.