Connecting IoT Data to ERP, CRM & BI: Patterns That Actually Work

The reason IoT data ends up trapped in a dashboard nobody reads is almost always the same: nobody integrated it into the systems where business decisions actually happen. ERP, CRM, BI, and field-service tools are where the action is. IoT data has to flow there, in a form they can use, on a cadence they expect.

Here are the integration patterns we use on real projects, and the traps that bite teams that skip them.

The four flows you need to support

A connected product almost always has four directions of integration:

1. IoT → BI / data warehouse — telemetry rolled up for reporting and historical analysis
2. IoT → ERP / field service — events that should trigger work orders, replenishment, or maintenance
3. IoT → CRM — events that affect customer records (warranty, usage tier, contract events)
4. ERP / CRM → IoT — configuration push, customer-driven changes flowing back to devices

Each direction has a different latency and reliability requirement. Treating them all the same is the most common mistake.

Pattern 1 — Streaming to a data warehouse

For the IoT → BI direction:

• Devices publish to MQTT broker (AWS IoT, Azure IoT Hub, self-hosted)
• Broker forwards to Kafka or a managed equivalent (Kinesis, Event Hubs, Pub/Sub)
• Kafka feeds:
  • A time-series store for live dashboards (TimescaleDB, InfluxDB)
  • An analytical archive for warehouse loading (S3/GCS in Parquet)
• A scheduled or streaming pipeline lifts data from the archive into Snowflake, BigQuery, Synapse, or Redshift
• BI tools (Power BI, Tableau, Looker, Metabase) read from the warehouse, not the live store

Why three layers, not one: BI queries scan large date ranges and join to dimensional data. Pointing them at the live time-series store kills the live store under load. The warehouse is purpose-built for this; use it.

See our time-series architecture post for the depth.

Pattern 2 — Eventing into ERP and field service

For the IoT → ERP direction:

The temptation is to write a webhook from your IoT cloud directly into the ERP. This works for a demo and breaks at scale. Use a queue.

• Stream processor (Kafka Streams, Flink, Lambda, Cloud Run) watches IoT topics for events worth acting on
• Each actionable event goes to a queue specifically for ERP consumption
• ERP integration worker pulls from the queue, calls the ERP’s API (SAP S/4HANA, NetSuite, Oracle Fusion), and confirms the message
• Failed calls go to a dead-letter queue with retry policy
• Idempotency keys prevent duplicate work orders from retries

The queue is the boundary that keeps a 5-minute ERP outage from becoming a 5-minute IoT outage. It is the single most important architectural choice for this flow.

Pattern 3 — Two-way customer record sync

For IoT ↔ CRM:

CRM integrations are bidirectional and high-stakes. A wrong write into Salesforce is a real problem.

What works:

• Salesforce has the customer record; IoT cloud has the device record
• A sync service maps device IDs to Salesforce account IDs at provisioning
• IoT events (device activation, warranty trigger, usage tier crossed) flow into Salesforce as platform events or via the Bulk API
• Salesforce changes (customer cancels, device reassignment, address change) flow back via Salesforce platform events into the IoT cloud
• All sync operations log the source-of-truth and the conflict resolution rule

The trap: bidirectional sync without a conflict-resolution rule will eventually corrupt one side. Pick “CRM wins for customer attributes, IoT wins for device attributes,” document it, and audit quarterly.

Pattern 4 — Configuration push back to devices

For ERP / CRM → IoT:

When a customer’s contract changes — say, they upgrade to a tier with more frequent telemetry — that change needs to land on their devices.

• Configuration changes go through a desired-state document (AWS Device Shadow, Azure IoT Hub Twin, equivalent)
• The shadow update is the source of truth; devices reconcile their state against it on connect
• Every shadow update is logged with the originating system (ERP, CRM, admin dashboard)
• A reconciliation job nightly compares ERP-of-record contract terms to active device shadows; mismatches go to a queue for review

This pattern keeps the device-side simple (it just reads its shadow) and the integration logic concentrated in the cloud where it can be tested.

The traps

Three things that bite teams skipping the patterns above:

1. Direct webhook from IoT broker to ERP. Works in dev, breaks under scale or partial outage. Both sides become tightly coupled to the other’s uptime.

2. Polling from ERP into IoT cloud. Constant polling adds load, hits API rate limits, and lags real-time events. Use platform events or webhooks; poll only as fallback.

3. No idempotency. Network retries are inevitable. Without idempotency keys, a single device event can trigger ten work orders. Field-service teams notice. They will also call you.

What we typically deliver

For an IoT ↔ enterprise integration engagement:

• Architecture document mapping all four flows with the queue / shadow boundaries explicit
• Idempotency contract for every external API call
• Conflict resolution rules for any bidirectional sync, signed off in writing
• Integration test harness that exercises partial outage scenarios, not just the happy path
• Reconciliation job that runs nightly and reports on drift between systems
• Observability hooks so each integration’s health is a first-class signal

The integration layer ages well or badly entirely on whether these are in place from day one. Adding them later costs three times as much.

If you are integrating IoT into an enterprise estate — SAP, Oracle, NetSuite, or Salesforce — we have shipped this combination more than once.