Building Real-Time Inventory Alerts from SAP Business One to WhatsApp

Of all the integrations I build between SAP Business One and WhatsApp, real-time inventory alerting is consistently the one clients get the most immediate, tangible value from — it directly prevents stockouts and lost sales, and it’s simpler to build than most people expect.

Defining “real-time” honestly

SAP Business One doesn’t natively push events out to external systems the moment inventory changes. What’s actually achievable, and what I recommend, is near-real-time via one of two mechanisms:

Polling via Service Layer

A scheduled job (in n8n, or any scheduler) queries the Service Layer at a short interval — every one to five minutes is typical — filtering Items or the warehouse-level stock endpoint for quantities below a defined threshold.

Database-level triggers with a message queue

For businesses needing tighter latency, a SQL trigger on the relevant SAP B1 tables (e.g. OITW for item-warehouse quantities) can write to a staging table or push a message to a queue, which a middleware service picks up and processes. This is more invasive of the SAP B1 database and needs care to avoid interfering with SAP’s own processes, so it’s reserved for cases where polling genuinely isn’t fast enough.

For the vast majority of SMEs, polling via Service Layer is sufficient and far lower-risk.

Designing the alert logic

Reorder points, not just “out of stock”

Alerting only when stock hits zero is too late to reorder without a stockout gap. Using SAP B1’s item-level reorder point and reorder quantity fields (already present on most implementations, even if unused) as the trigger threshold means the alert lands while there’s still time to act.

Avoiding alert fatigue

A naive implementation re-sends the same alert every polling cycle until stock is replenished, which trains staff to ignore the channel entirely. The middleware needs to track “already alerted” state — typically a simple flag or timestamp per item — and only re-notify after a defined cooldown period or once stock crosses back above the threshold and then below it again.

Routing by relevance

Sending every low-stock alert for every warehouse to a single WhatsApp group quickly becomes noise. Routing alerts by warehouse, item group, or responsible buyer — using SAP B1’s existing organisational data — keeps the notifications actionable for the person who can actually do something about them.

The WhatsApp side

Because these are business-initiated notifications rather than replies within a customer conversation, they need to use approved WhatsApp message templates. A simple, generic template (“Stock alert: {{item}} at {{warehouse}} is at {{quantity}}, below reorder point {{reorder_point}}”) covers most cases and avoids needing template resubmission every time wording changes slightly.

Media isn’t necessary here — plain text templates are faster to get approved by Meta and sufficient for an internal operational alert.

A realistic build sequence

1. Confirm reorder points and reorder quantities are actually populated and meaningful in the SAP B1 item master — this data often exists but has been left at defaults.
2. Build the Service Layer polling workflow with the alert-state tracking to prevent repeat notifications.
3. Get one simple WhatsApp template approved and route alerts to a single test recipient.
4. Extend routing logic to the relevant buyers/warehouse managers once the core logic is validated.

Takeaway

The technical pieces here — Service Layer polling, a threshold check, a WhatsApp template — are all straightforward individually. The value comes from getting the alert logic right: using real reorder points, avoiding repeat notifications, and routing alerts to the person who can act on them, rather than broadcasting noise.