Notifications operators actually act on
Two priorities, real read state, channel routing per event, and PRIMARY/SECONDARY actions that link to the exact record. The same bell, popover, and inbox — driven by the same notification model.
Notifications
Latest 4 events
Inventory variance on FO-11929
12 min ago
Cycle count flagged a shortage at L-A12-04 that affects fulfillment FO-11929:
- •
2 units short on SKU-4491
- •
Hospital tote T-4521 created
- •
Replenishment task RT-4002 queued
Replenishment ready for putaway
1 h ago
4 SKUs ready to bundle into a putaway list at DAL-01:
- •
SKU-4491 · 24 units to L-A12-04
- •
SKU-2210 · 18 units to L-B03-01
- •
SKU-8810 · 12 units to L-A05-12
- •
SKU-5512 · 9 units to L-A03-11
Webhook delivery failed
2 h ago
merchant-prod-v3 returned HTTP 500 for order.fulfilled — 2 retries scheduled:
- •
Endpoint /api/webhooks/cybership
- •
Last response 502 in 41 ms
- •
Next retry in 4 min with backoff
Receiving variance on PO-3398
3 h ago
SKU-4492 short by 2 units. Receiving paused while reviewer confirms count.
- •
Expected 60 · received 58
- •
Bay 2 · Warehouse Ops
Routing
Per-event channel + priority — set in settings, honored everywhere
Each notification type is configured independently. Urgent webhook failures land in-app and email; quieter cycle-count completions email only. Operators see the same routing in the bell, the inbox, and the email subject prefix.
Notification preferences
Order placed on hold
Sent when an order moves to ON_HOLD with a reason like inventory or address validation.
Webhook delivery failed
Sent on the second consecutive failure for a webhook endpoint, before retries exhaust.
Cycle count completed
Sent to the assignee and supervisor when a cycle count run finishes with discrepancies.
Purchase order fully received
Sent to the buyer and warehouse manager when a PO closes with all units received.
Notification model
What's behind the bell, in detail
A real per-user record with priority, channel, structured description, and typed actions. Same model drives the bell, the inbox, the popover, and the email.
STANDARD vs URGENT priority
Two priority levels with distinct iconography in the bell, the inbox, and the email subject line. Operators can scan urgent items first without filtering.
Per-event channel routing
Each notification type (order on hold, webhook failure, cycle count complete) routes independently to in-app, email, or both — set per role.
Actionable, not advisory
Every notification carries action links (PRIMARY + SECONDARY) that drop the operator on the exact record — order, fulfillment, cycle count, webhook delivery.
Webhook delivery + retry visibility
Webhook failures notify on the second consecutive failure with the endpoint, response code, retry schedule, and a link to the delivery log.
Read / unread state, real
Read state is a per-user flag, not a UI hack. Marking read in the bell, the inbox, or the popover is the same write to the same record.
Settings live next to the work
Notification preferences are a real settings page operators reach from the same nav as warehouses, members, and integrations.
Notifications are produced by automation rules and platform events. The same record is rendered in the bell, the inbox, and the email — same PriorityIcon, same description parser.
Site-wide notifications can target every member of a team for outages or maintenance windows — set on the same record with a single flag.
Bring your noisiest alert to a demo
We'll route it through the bell, the email, and the popover and show you what your operators would actually see.
Schedule a DemoExplore more of our features
MerchantOS
Self-service 3PL client portal with visibility into orders, products, billing, and fulfillment.
Automation Rules
Build visual workflows with triggers, conditions, actions, and execution logs.
Access Controls
Manage team members, invites, roles, permissions, API key roles, and warehouse access.