Warehouse automation: Service Bus + D365 business events

Distribution-center operators running Dynamics 365 Supply Chain Management increasingly integrate with physical warehouse automation - conveyor systems, goods-to-person robots, automated storage and retrieval. The business requirement is clear: when a robot completes a pick, D365 should know within seconds so downstream processes (packing, shipping, inventory update) can run.

The integration pattern is where teams diverge. Three options get proposed. Two of them miss the latency requirement.

The slow paths

Scheduled batch job reading updates every 15 minutes. Fine for reconciliation; fatal for operations. Pickers complete work that doesn't trigger downstream processes until 14 minutes later. Packing stations idle. Shipping cutoff times miss. The entire point of automation is undermined by the integration pattern.

Data Management Framework periodic imports. Same failure mode as scheduled batch with extra moving parts. DMF is a bulk-data tool, not a low-latency signaling tool.

Power Automate with standard connectors. Works at low volume for simple workflows. Hits rate limits fast when the warehouse throws hundreds of completion events per minute. Power Automate flow runs also carry overhead per execution that's fine for one-offs but expensive at scale.

The pattern that matches the latency requirement

Azure Event Grid or Azure Service Bus for the messaging backbone, tied to D365 business events on the F&O side.

Two patterns depending on requirements:

Event Grid for one-to-many, fan-out scenarios. When a pick completes, multiple consumers care - F&O updates inventory, the WMS confirms, the packing station reads the next pick. Event Grid delivers one event to all subscribers. Pub-sub done right.

Service Bus for queue semantics with ordering and guaranteed delivery. When events must be processed in order and exactly-once (e.g., serialized inventory moves), Service Bus queues carry the strict ordering. FIFO with session-based partitioning.

Most warehouse integrations use both: Event Grid for fan-out notifications, Service Bus for the specific subscribers that need guaranteed delivery.

Business events: the F&O side

D365 Business Events is the feature that lets F&O publish domain events to external consumers. When a sales order ships, F&O raises an event. When inventory goes below reorder point, F&O raises an event. When a batch completes, F&O raises an event.

Out of the box, business events can target:

• Azure Event Grid
• Azure Service Bus
• Microsoft Power Automate
• Custom HTTP endpoints

Warehouse automation scenarios work in both directions:

• F&O → warehouse system: shipping order created → Service Bus message → warehouse robot gets the pick list
• Warehouse system → F&O: pick completed → Event Grid event → F&O updates inventory, triggers next processing step

How the physical flow maps to events

Consider a goods-to-person robotic pick:

1. F&O creates a sales order with release to warehouse
2. Business event fires to Service Bus: "Release to warehouse: order 12345"
3. WMS middleware receives, assigns to a robot, returns pick list
4. Robot picks, sensors confirm
5. WMS publishes to Event Grid: "Pick complete for order 12345, items X/Y/Z"
6. F&O subscriber on the pick-complete event updates inventory, advances order status
7. Downstream: packing station gets notified, shipping label queued

Each step is an independent message exchange with its own latency budget. The stack measures <2-second total from physical action to F&O state update.

Custom business events for scenarios the standard doesn't cover

D365 ships many standard business events. When the scenario needs a custom event:

Custom business events extend BusinessEventsBase, define their payload schema, and register with the framework. The infrastructure (Event Grid delivery, retry, dead-letter) all comes from the platform.

Error handling that survives a busy warehouse

Warehouse operations don't tolerate gaps. The messaging pattern has to handle:

• Message failure - dead-letter queue collects events that can't be processed, alerting ops without blocking the live flow
• Duplicate events - idempotency keys on the consumer side prevent double-processing
• Out-of-order events - Service Bus sessions carry ordering when it matters; Event Grid with ordering via timestamp when eventual consistency is OK
• Throughput spikes - warehouse peak hours produce order-of-magnitude more events; Service Bus auto-scales and Event Grid is elastic by default

Security and identity

Warehouse systems talk to Azure via service principals with narrow permissions. Event Grid topics and Service Bus queues are scoped per integration pattern. TLS on all communication, private endpoints where possible.

What ships with this architecture

A working warehouse-to-F&O integration has:

• D365 Business Events enabled with target endpoints configured
• Service Bus queues (with sessions where ordering matters) and Event Grid topics (for fan-out)
• WMS or custom middleware as the event producer on the warehouse side
• F&O subscribers for events flowing back (typically via a custom service or a subscribed Power Automate)
• Dead-letter queue monitoring with alert on non-zero backlog
• Latency dashboard tracking end-to-end time from physical action to F&O state

The event-driven architecture is more work upfront than a batch job. It's the only pattern that delivers the latency warehouse automation requires.