How to Monitor Inventory Levels and Alert on Low Stock

Get automatic alerts when product inventory drops below a threshold so you can reorder before running out.

What This Integration Does

Running out of stock on a popular SKU costs you real revenue and damages search rank if customers see "sold out" repeatedly. Most platforms have low-stock notifications, but they're per-store and noisy. This workflow scans every channel (or your central source of truth) on a schedule, applies per-product thresholds, and posts a clean digest to Slack or email with what's low, what's about to go, and what to reorder.

The workflow runs on a schedule, fetches current levels, joins them against a per-SKU threshold table, and emits a single consolidated alert per run. The previous run's alert state can be stored in MongoDB so the workflow can avoid alerting on the same SKU repeatedly when nothing has changed.

Prerequisites

An inventory source: Shopify, WooCommerce, BigCommerce, NetSuite, or MongoDB.
A per-SKU threshold table (stored in MongoDB works well) with { sku, warningLevel, criticalLevel, reorderQuantity }.
A Slack connection and / or an email connection for alerts.

Step 1: Schedule Trigger

Drop a Trigger node and set it to Schedule. Every 2-4 hours is the typical sweet spot, or daily at 06:00 if you reorder once a day.

Step 2: Fetch Current Inventory

Add a Connector node for your source:

shopify get-inventory-levels for live levels per location
woocommerce list-products filtered to in-stock products and projected to stock_quantity
bigcommerce list-products projecting inventory_level
netsuite run-suiteql against item for warehouse stock
mongodb find-documents against your central inventory collection

Step 3: Load Per-SKU Thresholds

Add a Connector node calling mongodb find-documents on the inventory_thresholds collection. Hold the result in a variable so the next step can do an in-memory join instead of querying per product.

Step 4: Filter to Low-Stock SKUs

Add a Transform node that joins inventory with thresholds and projects each SKU to a level: ok if above warning, warning if between critical and warning, critical if at or below critical. Filter to anything that's not ok. If there's nothing left, add a Condition to short-circuit and end the workflow without sending an alert.

Step 5: De-duplicate Against the Last Run

Add a Connector node calling mongodb find-documents on last_low_stock_state and compare. Only alert on SKUs whose state changed (e.g. moved from warning to critical or moved into either bucket since last run). Then call mongodb update-documents to persist the new state for next time.

Step 6: Send the Alert

Add a Transform node that builds a tidy Slack-friendly message: grouped by criticality, with SKU, name, current level, threshold, and suggested reorder qty. Then a Connector node calling slack send-message with the formatted text. Optionally route critical-only items to a high-urgency channel or page.

Tips

Per-SKU thresholds beat a single global number. Fast-movers need a higher warning level than tail SKUs.
Use AI to predict stockout dates. An Agent Mode Connector node fed the last 30 days of sales can return a structured { daysToStockout, suggestedReorder } per SKU and make the alert actionable.
Auto-create reorder tasks. Add a Monday.com or Jira branch that creates a task for the purchasing team when a SKU moves to critical.
Don't alert at 03:00. Schedule the workflow during working hours so the team can act on what they see.

Common Pitfalls

Multi-location inventory. Shopify sums look fine until you realize 90% of stock is at a closed warehouse. Threshold per-location, not per-SKU sum.
Alert fatigue. Without state de-duplication, you'll get the same SKU listed every run. Persist the last alerted state and only re-alert on transitions.
Reserved stock. Shopify's "available" already subtracts reserved orders, but your ERP usually doesn't. Pick one definition and stick with it.
Time zones for "daily at 06:00". A schedule in UTC fires at a different local time depending on DST.

Testing

Pick three known SKUs and temporarily lower their thresholds to above the current level. Run the workflow once manually; the alert should fire with those SKUs listed. Run a second time without changes; the alert should not re-fire. Then restore the real thresholds and turn on the schedule.