IoT Hub Message Routing vs Event Grid — Why Telemetry and Events Are Not the Same Problem

A machine sends a temperature value every few seconds, it sends a cycle count, it sends vibration data, current draw and a run state. Then, at some point, its connection drops. People often call all of that events. Azure uses the word too, so the confusion is understandable, but a stream of measurements and a notice that something changed create two very different architecture jobs. One path needs to preserve the production record. The other needs to tell the right system or person that it may need to react. If you treat both paths the same, you either build a very expensive alarm system for routine sensor data, or you bury urgent signals in a data pipeline nobody watches. So let's follow one machine through a normal production shift, because that makes the difference much easier to hear. A press line, a sensor stream, and one missing signal. Picture a press line producing formed metal parts during a live work order. The line has a PLC, a few sensors, and an industrial gateway that connects the OT network to Azure. None of that is unusual. Most plants already have some version of this, even if the gateway talks to a mix of old and new equipment. Every few seconds, the gateway sends a device to cloud message into Azure IoT Hub. The message may include press temperature, vibration level, cycle count, energy draw, and whether the machine reports a running idle, faulted or stopped state. It may also carry a device identifier and a timestamp from the gateway. That flow creates a record over time. The MES, the manufacturing execution system, tracks a different part of the story. It knows which work order is active, which operation should run, which recipe applies, perhaps which operator signed into the cell, and whether the order has started or completed. The machine can tell you that a cycle happened. The MES can tell you which production operation that cycle belongs to, both matter, but they don't come from the same place. Now imagine the press starts its shift normally. Temperature rises as the equipment warms up. Cycle counts increase, vibration stays inside its normal operating band. A production engineer may want that data later to study where a maintenance engineer may wanted to watch for a gradual change. A data team may use it to build a reliable history for analysis in Microsoft fabric. Those consumers don't need a new workflow for every reading. They need the facts to keep arriving in the usable sequence so they can reconstruct what happened across the shift. A planner has another concern. The planner doesn't need a notification every time the press completes a cycle, because that would turn production planning into a fairly noisy hobby. The planner needs trustworthy evidence when production has actually slowed, stopped, or moved off plan. The evidence may start with machine data, but it needs MES contacts before anyone changes a schedule. Then the gateway loses its connection. That is a different kind of message. The loss of connection may need a prompt response from an IT or OT support team. A workflow might open an investigation. It might notify the line support group. It might check whether the device has reconnected, whether other devices on the same network, segment also dropped, or whether the gateway itself reports a fault. But notice what the connection loss does not prove. It doesn't prove that the press stopped. The press may continue running under local PLC control. It doesn't prove the work order is late. It doesn't prove a safety issue. And it doesn't tell a planner which alternative machine can take the work. A disconnected gateway tells you that cloud visibility has changed. That's enough to trigger an investigation. It isn't enough to write the production story. This is where teams often create trouble without meaning to. They see the word "event", then send every telemetry reading through an event triggered workflow. A sensor value arrives, a function runs. Another value arrives, another function runs. Soon, ordinary operating data creates a flood of small reactions. Each one carrying less context than the person who needs to act. The opposite mistake can happen too. A connection change enters a large telemetry pipeline, lands in storage, waits for a consumer, and eventually appears in a report. Technically the signal arrived. Operationally, the team who needed to know may hear about it far too late. Think about the two messages leaving that same press line. One message says, "The press temperature is 82 degrees, and the cycle count is still increasing. It belongs in a continuous operational record." The other says, "This device connection changed state. It belongs in a response path, where subscribed systems can decide whether they need to act. They may leave the same gateway, they may pass through the same IoT hub, but downstream they have different jobs." Telemetry means a time-ordered record. Telemetry is a record of repeated measurements over time. One reading has limited meaning on its own, but the sequence tells you how the machine behaved during a real production run. Take the press line again. A temperature reading of 82 degrees might be normal. It might also be a problem. You can't tell from that one number unless you know what came before it, how fast it rose, what the press was doing at the time, and where the similar runs followed the same pattern. The order creates the story. A machine may start from cold, then enter a warmer period, where temperature and current draw climb. After that it reaches a stable run state. Much later, vibration might begin to creep upward while cycle time stretches slightly. The line then stops, perhaps for a planned material change. Perhaps because of fault occurred, perhaps because the operator paused it. This facts only form a usable production record when you keep the sequence intact. If a vibration reading from after the stop appears before the last running state message, a downstream system can tell the wrong story. It may classify a normal shutdown as a fault. It may calculate a downtime period that never existed. It may attach the wrong sensor pattern to the wrong batch. That kind of error rarely looks dramatic in a cloud architecture meeting. It looks like a small time stamp issue, or a consumer problem someone plans to clean up later. On a factory floor though, those small errors can turn into hours of people arguing over which system tells the right version of the shift. And this is where OEE, overall equipment effectiveness, often gets misunderstood. OEE needs more than a machine counter. It needs a defensible timeline of planned time, runtime stops, speed loss production count, and quality results. Some of that comes from machine telemetry. Some comes from the mayors. But if the telemetry record arrives late, disappears during a network gap, or lands out of sequence, your OEE calculation can become a polished answer to the wrong question. Condition monitoring works the same way. A maintenance engineer usually doesn't care only that vibration passed a number once. They care whether the value rose over days, whether it changes under a certain product load, whether the pattern repeats at a particular point in the cycle, and whether the reading returns to normal after maintenance. That analysis depends on a record you can inspect again. Think of telemetry as a production logbook that writes itself. It records what the equipment reported, when it reported it, and in what order the signals appeared. The logbook isn't useful because somebody reads every line the instant it arrives. It's useful because later when a question comes up, you can trace the sequence and test an explanation against the record that also explains why one consumer is rarely enough. Your operational team may need near real time processing for a current condition. Your data engineers may need the same telemetry for a curated history. A quality team may need to retrieve a slice of the record tied to a serial number or batch. And months later an engineer may need to compare a failure pattern with a prior production run. A customer has a different job. They shouldn't need to compete for the same one time notification. And they shouldn't depend on one workflow keeping perfect notes for everybody else. A proper telemetry part lets consumers read the stream for their own purpose. It retains raw facts long enough for traceability and later analysis. It also accepts an uncomfortable but normal manufacturing condition. Messages can arrive late and devices can lose contact. When that happens you need to know the difference between a missing measurement and a machine state. A gap in telemetry might mean the gateway lost network access. It might mean the device rebooted. It might mean the sensor stopped sending. None of those explanations should quietly turn into the machine was down just because the data stopped. So the telemetry pipeline needs time, sequence, device identity and enough source detail to interpret gaps. Honestly, it needs consumers that can handle duplicates too because reliable industrial messaging often means a message can appear more than once. Receiving the same fact twice is safer than silently losing it but your processing logic still needs to recognize it. This is a stream problem. It needs replay, retention and independent readers. A discrete event has a different job. Events mean something requires attention. An event tells a different kind of story. It says that a condition changed or that something happened and one or more systems may need to react. Think about a device being registered in IoT Hub. Somebody may need to assign it to a plant and owner and an asset record. When a device connects, a support process may record that the cloud link is active. When it disconnects, a support team may need to investigate whether the problem sits in the gateway, the network, the device or the cloud path. Those are events because they change the state of the world in a way that can start work. The recipient doesn't usually need a long sequence of readings before it can respond. It needs a clear notice, an identity, a time, and enough detail to decide the next step. A workflow may create a support ticket and as your function may check a device record, a logic app may send a message to the team responsible for the site. That response path needs to be fast and loosely connected. The system that handles device registration shouldn't need to know anything about vibration analysis. When responsible for access control shouldn't need to consume the same high volume stream as the quality team. Each subscriber can receive the event it cares about, then do its own work without becoming part of the production data pipeline. Consider a new gateway arriving at a plant. The gateway gets registered in the cloud. That registration can trigger a process that creates an asset record, checks the device naming rule records the site and assigns an operational owner. None of those actions need the gateway to send thousands of measurements first. They need one reliable notice that the device exists or take a disconnect event during a shift. A support workflow receives the notification and checks whether the gateway reconnects shortly after. It may compare the event with network monitoring data. It may raise the issue to the right team if other devices in the same cell disappear at the same time. That workflow responds to a change condition. It doesn't need to reconstruct every press cycle since the start of the day. This is why I separate a response signal from an operational record. A response signal says something deserves attention now. It can prompt a person, start an automated check or create a work item. The signal needs clear ownership. If nobody owns the next action, the event simply becomes another message in another system. Factories already have enough of those. A useful event also has a boundary. Suppose the temperature in our press moves above a limit. The raw readings still belong in the production record because an engineer may later need the full pattern. But a rule can interpret those readings and emit a separate event. Temperature condition requires review. That second message isn't pretending to replace the measurements. It tells a maintenance process that the measurements crossed a defined business or engineering threshold that split keeps the architecture honest. The source data answers, what did the machine report? The event answers, what should a person or system consider doing because of it? You may send both at nearly the same time, but they carry different meaning and they should have different contracts. A fire alarm and a chart recorder both relate to safety but they don't do the same job. The chart recorder tracks conditions through time so an engineer can inspect the pattern. The fire alarm tells people to react. It would replace the chart recorder with a room full of alarms and nobody would ask people to inspect a long trend chart before leaving a dangerous area. Industrial systems need the same discipline. Not every notification demands a human response either. Some events start technical checks. A device created event can trigger a registry update. A disconnect event can trigger a status check. A completed inspection can prompt a system to release the next workflow step. In each case, the event announces that a boundary was crossed. Then a subscriber decides what to do next. That decision may still need more context. A device disconnect can start an investigation, but it can't by itself establish production loss. A device created event can start setup work, but it can't prove the device configuration is correct for a machine. An event opens the door to a response. It doesn't contain every fact needed for a safe operational decision. Keep that distinction in mind because telemetry can absolutely create an event. A stream rule, an engineering limit, or a model result may decide that the data now requires attention. The event and the telemetry remain separate concerns even when one leads directly to the other. Why? Everything is an event breaks down on the shop floor. Software teams often use the word event very broadly. A button click is an event. A record update is an event. A sensor reading is an event. At one level that language is fine because all of those things happened at a point in time, but the factory doesn't care about language purity. It cares whether the information arrives in a form that supports the next operational job without adding noise, losing history, or waking up a workflow for no good reason. Picture a gateway sending a temperature, pressure, vibration value, and power reading every few seconds from several machines. If every message enters a notification path, each reading can trigger a downstream handler. A function wakes up, a logic app evaluates a rule. A web hook receives a call. Another system writes a status record. Nothing necessarily fails at first. That's why this design can survive a proof of concept. In the number of devices grows, the sampling rate changes, and more teams subscribe because the messages seem useful. The maintenance team wants one view, quality wants another, energy management wants a third. Somebody adds an email rule because a sensor value looks unusual and soon the same normal operating pattern starts several unrelated processes. A temperature reading isn't an incident, it may contribute to an incident later. It may be part of a pattern that points to where poor cooling, an incorrect recipe, or a sensor fault. But treating every measurement as an urgent business signal forces each downstream consumer to rediscover the same distinction. Is this just data or does somebody need to act? That is wasted architecture effort. You move filtering, aggregation, and state tracking into dozens of small handlers where it becomes hard to test and even harder to trace when a production engineer asks a simple question about last Tuesday's shift. The delivery semantics create another problem. A stream consumer often needs to reason about sequence. It needs to know whether a run-state change came before account increase, whether a threshold occurred during a production cycle, and whether a gap reflects a real stop or loss of connectivity. A notification system doesn't exist to rebuild that kind of timeline. Event Grid doesn't guarantee delivery orders. If you use it as the main home for high volume telemetry, a subscriber can receive messages in an order that doesn't match the order in which the machine produced them. You can try to repair that in every handler. Add timestamps. Hold messages briefly, sort them, deduplicate them, track the last known state. When you discover that your simple event-driven design now contains several home-built stream processes, each with slightly different logic and no shared record of truth. That's not an event-driven architecture. That's a distributed troubleshooting exercise with better branding. The reverse mistake causes trouble too. Teams sometimes take sparse lifecycle signals, such as device registration or a connection change, and send them only into a broad data path. The notification reaches storage and becomes available for analysis, but no subscriber receives a prompt trigger to check the device, update a registry, or start an owner assignment process. The data exists yet the work doesn't start. Those two failures come from treating all messages as interchangeable because they share a transport name. They aren't interchangeable. Their volume may differ. Their need for order may differ. Their consumers may differ. Most of all, the question each message supports may differ. A telemetry message often asks, "What has this asset been doing?" A lifecycle event asks, "What changed and who should check it?" Other questions can refer to the same device that doesn't turn them into the same data contract. There is also a people problem here, not just a cloud problem. When ordinary sensor traffic starts workflows, plant teams lose trust in alerts. They learn that a notification might mean anything from a routine reading to a real production issue, so they begin to ignore it. That response makes perfect sense. The system trains them to treat its messages as background noise. Good industrial architecture protects attention. It keeps the continuous record available for analysis, and it raises a response signal when a defined condition needs a response. Those are connected parts, but they should stay distinct. With that boundary clear, we can define the first Azure role without turning this into a product tour. What Azure IoT Hub actually handles? Azure IoT Hub sits at the point where a physical device meets the cloud. In a plant that device may be an industrial gateway, a sensor package, a PLC connected edge computer, or a purpose-built machine controller that can securely communicate beyond the OT network. Its first job is identity. Each device connects with its own identity and access rights, rather than every machine sharing one broad connection secret. That matters in manufacturing because a device isn't just another application client. It belongs to an asset, a line, a site, and an owner, and it may need to lose access without disrupting every other device in the plant. You can revoke or change a device's access independently. You can track which device communicates with the hub. And you can build a managed boundary between equipment networks and cloud services, rather than allowing every gateway to send data directly into every downstream system. That boundary doesn't remove the need for OT security. It doesn't replace network segmentation, firewall rules, industrial protocol controls, or a sensible edge design, but it gives the cloud side a controlled entry point for device communication. The next job is device to cloud messaging, a gateway can send its telemetry to IoT Hub, where the platform accepts the message under the device identity that sent it. The message may carry sensor values, a machine state, an edge-calculated result, or a production signal prepared by software near the machine. That doesn't mean IoT Hub understands the press, the recipe, or the work order. It knows that an approved device sent a message. The meaning of that message still depends on the data contract you define, and the manufacturing context you connect later. That distinction saves a lot of bad assumptions. If a gateway sends a field called state with the value running, IoT Hub can receive it safely and forward it based on your rules. It can't decide whether running means producing good parts, dry cycling, setup, rework, or a machine moving without material. For MES and asset model, still carry that part of the truth. IoT Hub also supports communication in the other direction, from cloud to device. That can support commands, configuration changes, acknowledgments, or a request for a device to perform a defined action. In a factory though, cloud to device messaging needs restraint. A cloud command isn't a substitute for a safety-rated control system. If a command could affect machine motion, product quality, or operator safety, you need clear control rules, local safeguards, and an OT design that can behave safely when the cloud disappears. The cloud can coordinate or request actions. The machine control layer remains responsible for safe physical behavior. There is another part of IoT Hub that often gets mixed up with telemetry, device twins. A device twin is a cloud side document that represents state associated with a device. It separates desired properties, which the cloud wants the device to apply, from reported properties, which the device reports about its current condition or configuration. Imagine a gateway assigned to line two. The cloud may set a desired sampling interval or a configuration version. The gateway reports which version it actually applied when it last checked in and perhaps which firmware build it runs. That creates a manageable conversation about configuration without treating every change as a command sent at the exact same moment. For industrial systems, twins work well for device and gateway state. They don't automatically become a complete digital twin of the factory. A device twin can describe a gateway's reported software version. It doesn't buy itself, describe which machine the gateway observes, which cell contains that machine, which products it can produce or how a failed sensor affects a customer order. You need an asset model, MES links and sometimes a knowledge graph for that wider context. So think of IoT Hub as the device facing boundary. It handles secure device identity, device to cloud messages, cloud to device communication and device management state in a way that fits connected equipment. It doesn't replace the PLC, it doesn't replace the mess, it doesn't turn raw sensor data into production truth simply by accepting it. Since IoT Hub accepts a message another question takes over, where should that message travel and which downstream system should receive it? IoT Hub message routing as the telemetry data plane. Once a device message enters IoT Hub, message routing decides which approved downstream path receives it. Think of routing as traffic rules at the edge of the cloud. The device sends one message and IoT Hub evaluates rules you define before it sends that message onward. That matters because a plant rarely has one consumer for telemetry. Transparenced data may need to feed a stream path for current operational analysis, while another copy needs to land in storage for traceability. A separate consumer may need a filtered set of messages for an application that tracks energy or machine condition. Routing lets you send those messages to selected endpoints without teaching every gateway about every downstream system. The gateway sends to IoT Hub. The cloud architecture takes responsibility for distribution from there. The route can inspect information attached to the message. That includes application properties, system properties and where your design needs it parts of the message body. It can also use device twin tags and properties as part of a routing query, say a gateway sends telemetry from several assets through one connection. The message can carry an asset identifier, a signal type and a source timestamp. You might route production state messages to one path, energy readings to another and diagnostic messages to a third. Or you may use a twin tag that identifies a device as belonging to a particular site or production area, then apply a route based on that managed device context. The important part is where that filtering happens and you don't want every downstream consumer receiving every message, then each team writing its own logic to discard most of the traffic. That creates duplicate work and inconsistent rules. A route gives you a controlled first decision about where a message belongs. It doesn't decide what the message means operationally. It decides where the message should go. IoT Hub can route device to cloud messages to Azure event hubs, Azure storage, Azure service bus queues or topics and on paid IoT Hub tears that supported Azure Cosmos DB. Each destination fits a different downstream job, so naming the endpoint alone doesn't finish the design. Event hubs usually fits when you need a stream that several independent consumers can read. One consumer may process current data, another may prepare data for later analysis. The stream lets those consumers work at their own pace, subject to the retention and consumer design you choose. Azure storage fits when you need an economical raw record that can support later inspection audit work or batch processing. Service bus can fit when telemetry produces a defined business message that an application must process through a queue or topic pattern. Cosmos DB can fit selected operational application patterns where low latency document access makes sense. None of those choices turns telemetry into a business decision. They give the telemetry a destination where a later process can do useful work with it. There is a practical advantage here that people sometimes miss. IoT Hub message routing doesn't add a separate routing charge beyond the telemetry ingress charge. If you root the same incoming device message to several configured endpoints, the routing itself doesn't turn that one incoming message into several IoT Hub ingress charges. That doesn't mean the rest of the architecture costs nothing. Storage, stream processing, downstream compute and data movement all need their own cost and capacity planning, but it does mean you shouldn't force unrelated consumers to share one fragile path just because you assume each additional root creates another IoT Hub ingestion will. Ordering also shapes the decision. Microsoft documents that IoT Hub message routing maintains the order of routed messages. For production telemetry that gives you a stronger starting point than a notification path where consumers may receive messages in a different order from the source. Still, don't turn that statement into a guarantee your full business process can't support. Your partition strategy, consumer design, timestamp rules, retries and device behavior still matter. A gateway may buffer data during a network interruption. A device clock may drift. A consumer may process the same message more than once, because the delivery model aims for at least once delivery. Routing preserves an ordered path, but your application still needs to identify duplicates and reason carefully about source time versus cloud arrival time. That's normal engineering, especially in OT and IT convergence. Physical systems don't pause politely while networks reconnect. So, the right way to view IoT Hub message routing is as the telemetry data plane. It takes device messages that need a controlled, filtered ordered path and directs them to the services built to retain, process or distribute operational facts. A route can move the facts reliably. It doesn't decide which person needs an alert when those facts point to a problem. Route 1 preserving the production story. Let's put a real route around the press line. The gateway sends a message each time it has a new set of readings worth sending upstream. That message needs more than a temperature and a vibration value if you want to use it later. It should carry a source timestamp, a sequence number where the gateway can provide one, the asset identity and a clear machine state. Context travels with the message where it can. For this press, the gateway might also include the active work order reference that it received from the local production system or a correlation ID that lets another service connect the reading to the right operation. I'd still treat the MES as the authority for work order status. But adding a reference to the telemetry creates a usable link between a physical signal and the production record. A message could say in plane terms, this came from press 12. It was the next message in this device sequence. The press reported that it was running and the gateway observed it at this time. It may also carry a cycle count, motor current, die temperature, vibration values, and a small set of quality related process signals. That's enough to reconstruct part of the shift later. At IoT Hub, a route can select this production telemetry based on properties that the gateway sets consistently. You might mark the message type as production telemetry. You might separate it from gateway diagnostics, configuration acknowledgments, or infrequent maintenance status messages. The exact naming matters less than discipline. One who produces and consumes the data needs to mean the same thing by it. The selected telemetry can then flow into Azure EventHubs. EventHubs gives downstream consumers a stream they can read independently. One consumer might calculate current operating conditions, another might prepare data for a data platform. A third might watch for data quality issues, such as a gateway that suddenly stops sending one signal while continuing to send everything else. Those consumers should not block each other. That matters during a busy shift. A data engineering process may fall behind for a short period. And near real time process may still need to continue. If both depend on one custom service reading a message once and forwarding it perfectly to every other system, you've created a narrow point of failure right in the middle of your production record. The stream creates a better boundary. Alongside that streaming path, I'd usually keep a raw copy of the incoming messages in storage. Not because raw data is automatically useful, but because you'll eventually need to answer a question that the curated model didn't anticipate. An engineer may ask why a condition model flagged a machine on a specific day. A quality team may need to inspect the sensor history around a batch issue. An OT engineer may need to compare the source payload with what a downstream process interpreted. Without a retained raw record, every one of those questions turns into a hunt through transformed tables, partial logs, and somebody's memory that gets old quickly. The raw copy should preserve the original device facts and the technical metadata that explains how those facts arrived. Keep the device identity. Keep source time and cloud receipt time were available. Keep the message properties that controlled routing. If the gateway assigns a sequence number, retain that too. Later processing can clean, normalize, and enrich the data. The raw record should stay closer to what the device actually sent. From there, a prepared operational data set can move into Microsoft Fabric through a pipeline that fits your data design. I'm being deliberate with that wording, because Fabric isn't a magic destination where raw machine messages somehow become trusted production facts. Before data reaches reporting or wider analysis, you need to decide how to handle device clock errors, later rivals, duplicate messages, unit conversions, missing values, and changes to the gateway payload. You also need to connect the signal to the asset model and where the use case needs it to a me as production context. That prepared layer might turn a raw message into a statement such as press 12, ran during this operation window with these process readings against this work order reference. The transformation needs clear rules and those rules need an owner. Otherwise, a clean looking table can hide a fairly messy interpretation. Once Fabric receives prepared operational data, power BI and other consumers can use a model built for their question. A production engineer may inspect patterns by asset and shift. An energy analyst may compare consumption across lines. A maintenance team may review trend history around a known fault. Each view starts from the same production story. Notice what the root itself has done. It has moved and preserved machine facts. It has given several consumers a controlled way to read them. It has supported both current processing and later investigation, but it hasn't decided whether anyone needs immediate attention. That requires a separate response signal with a clear reason for action. Why ordering matters more than it sounds? A production record only works if you can place facts in the right sequence. That sounds obvious, but it's one of those details that stays invisible until someone tries to explain a stop, a quality issue, or a count that doesn't match the MES. Take a press cycle. The gateway reports that the press entered run state. Then it reports cycle counts increasing. A process value moves outside its normal band. Finally, the press reports a stop. If you can preserve that sequence, a later consumer can ask sensible questions. Did the process condition appear before the stop? Did the stop happen during the active operation? And did production resume after an operator action? The order carries meaning. Now imagine the same messages arrive in a different order downstream. A stop arrives first. Then a cycle count arrives that actually occurred before the stop. Then the process value turns up. A simple state calculation may conclude that the press produced parts, while stopped, or that the quality condition happened after production ended. Neither conclusion needs to be true. The system only lost the sequence. Downtime windows are a good example. Many teams calculate downtime by taking the time between a machine entering a stop state and returning to a running state. That logic seems simple until you include late messages, a gateway reconnect, or repeated delivery of the same state change. If the consumer treats cloud arrival time as a machine time, it can create a downtime window that belongs to the network rather than the machine. If it accepts every duplicate as a new state change, it can split one stop into several smaller stops. Then somebody asks why OEE dropped on a line that operators insist ran normally, and the answer sits buried in message handling logic. That's why I'd keep several time concept separate. The source timestamp tells you when the device or gateway observed the condition. The IoT Hub receipt time tells you when Azure accepted the message. Processing time tells you when a downstream service handled it. Those times can differ, especially when an edge device buffers data during a network loss and sends it after reconnecting. None of that means source time always wins. These clocks can drift, gateways can stamp a message after collecting the data. Sometimes the machine controller has the most trustworthy clock and sometimes it doesn't. You need an explicit rule for which timestamp supports each operational question, rather than letting whichever field appears first in a dataset decide the story. Partitioning deserves the same level of care. A routed path can maintain message order, but order has to relate to the unit of work that matters. If messages from one asset land across partitions without a consistent partition choice, a consumer may not see the full sequence as one ordered stream. For a machine level state reconstruction, you usually want a stable way to keep that machines related messages together that doesn't mean you put an entire plan through one partition. You still need throughput and parallel processing. It means you choose a partition approach that matches the question. A single asset, a gateway, or another defined source boundary may provide the right grouping, depending on how the data arrives. Then there's duplicate delivery. IoT Hub message routing follows an at least once delivery model. In plain English, a downstream endpoint can receive the same message more than once. That protects against silent loss, which is the right bias for industrial data, but it means every consumer needs a duplicate strategy. A sequence number can help. Device-generated message ID can help. A composite identity built from device ID, source time, and sequence can help if the source can create it consistently. The exact method depends on the equipment and gateway software, but the principle stays the same. A consumer must recognize whether it has already processed this production fact. Don't confuse order delivery with exactly one's business outcomes. Even when messages arrive in order, a consumer might crash after updating a table, but before recording its checkpoint. When it restarts, it may process the message again. Or two downstream systems may interpret the same machine state differently because their business rules differ. Transport order can give you a stable foundation. It can't remove the need for, idempotent processing, clear data ownership, and careful state logic. That's not a flaw in the platform. It's what reliable distributed systems look like once they meet physical equipment and imperfect networks. For telemetry, this work earns its place because the sequence itself supports analysis, traceability, and production facts. But some messages don't need a consumer to reconstruct history. They need a team or system to react to a change, and that takes us from data transport into response signals. What Azure Event Grid actually handles? Event Grid handles the moment when something changes and other systems need to know about it. It uses a published subscribe model which sounds abstract, until you put it in a plant, a device, an Azure service, or an application publishes a notice. Systems that subscribe to that type of notice, receive it and decide what to do. They don't need to sit there reading a long stream and waiting for their one relevant message. Event Grid pushes the event to them. That fits work which starts because of a change. A device gets registered, a device disconnects, a device comes back online, an application detects a condition that needs review. Those events can go to separate handlers, and each handler can stay focused on its own job instead of becoming another consumer of the full telemetry flow. Think of a maintenance support process. It may care when a gateway disconnects because that means the plant has lost cloud visibility for a part of the line. An asset management process may care when a device gets created because it needs to check ownership and site assignment. A security process may care when a device gets deleted because it may need to remove related access or inspect what changed. Those processes don't need the same destination. With Event Grid, one event source can publish a notice and many subscribers can receive it. An Azure function can run a small piece of code to validate a condition or update a record. A logic app can start a workflow that sends a message, creates a task, or connects to an approved business system. A web hook can notify a service outside Azure where that makes sense for the architecture. Each subscriber gets a copy of the event intended for it. That fan outmodel matters when different teams own different reactions. The team that manages device identity shouldn't need to wait for the team that owns maintenance workflows. The maintenance process shouldn't need access to the provisioning logic. Event Grid lets them react independently to the same change with each subscription defining what it wants to receive. But Independence also means the subscribers must act defensively. Event Grid delivery follows an at least once model. A handler can receive an event more than once so it needs to process the event safely if a retry occurs. It also doesn't promise that events arrive in the order they happened. A handler can't blindly assume that a connection notice gives it the full and final current state of a device. So this kind of work that is usually manageable. A disconnect notification should often trigger a check, not an irreversible conclusion. The handler can inspect current device state, query a registry, or test whether the device has already returned. It can record the event for audit purposes, then decide whether the condition still needs action. That approach fits an event notification model very well. The event itself needs enough information to point the handler in the right direction. It has a type that tells the subscriber what kind of change occurred. It includes a subject which commonly identifies the affected resource or device. It also carries event data that the handler can inspect before it starts its work. For an industrial solution, the device ID gives you a technical starting point. Your own asset model then connects that device to a gateway, machine, cell, line, site, and owner. Event Grid carries the notice. It doesn't hold the whole factory model in its head. That distinction protects you from a common design mistake. A subscriber receives a device disconnected event then assumes it knows that a press stopped producing. It knows a device connection changed. Any production conclusion must come from the right mix of machine state, MS facts, and asset context. Event Grid is a notification fabric, not an industrial historian. It is built to distribute notices in near real time, so reactive systems can start their own work. It doesn't replace a retained machine record. And it isn't the place to reconstruct hours of sensor behavior after a quality problem. You can think of it as the part of the architecture that says, "A known change occurred," these systems asked to hear about it. The next action can be a technical check, a workflow, a record update, or a message to an accountable person. That makes it a strong fit for event-driven integration, particularly when many separate handlers need the same notice without tight coupling between their applications. IoT Hub can publish certain device and telemetry related events into that notification fabric. The details of which events it publishes and the limits that come with that integration shape whether event grid belongs in a specific manufacturing design. IoT Hub Event Grid integration. IoT Hub can publish selected device events into event grid, which gives you a direct bridge from connected equipment into a wider set of reactive Azure workflows. The event types matter because they tell you what IoT Hub is actually announcing. It can publish device created and device deleted events. It can publish device connected and device disconnected events. And it can publish device telemetry events when a device sends telemetry to the hub. Each event includes a subject that identifies the device. In practice, that subject follows the device identity path in the form of devices devised. That might sound like a small implementation detail, but it gives subscription rules a clean way to focus on a group of devices without asking every handler to inspect every event. Say your plant names gateways by site and production area. A subscription can focus on devices whose IDs begin with a site or line prefix. Or a handler can receive a device event, take the device ID, and use the asset model to find the machine, cell, owner, and support group linked to that gateway. The event carries the technical identity. Your manufacturing model supplies the operational meaning. Telemetry events through event grid need a little more discipline than lifecycle events. IoT Hub requires the telemetry payload to contain valid JSON. The message content type must be set to application JSON and the content encoding must be utf8. If those fields aren't set correctly, IoT Hub can't present the telemetry payload to event grid in the expected structure. That can seem annoyingly strict when you first meet it, but it forces a useful question, are your gateways publishing a defined message contract? Or are they just forwarding whatever shape of data happened to come from the equipment? For a manufacturing design, define that contract early. A telemetry message might include asset ID, source time, sequence, signal type, and the actual readings. You may also use message properties for details such as site, line, or data classification. When you later create event grid subscriptions, those fields give you ways to direct only the relevant notices to the systems that asked for them. This can work well when the same event needs broad fan-out. Imagine that a new industrial gateway is registered. The asset onboarding process needs to create or verify an equipment link. A security workflow needs to verify its owner and access status. The operations support team may need to confirm that the device belongs to the right plant and network zone. Those are separate reactions to one device created event. With event grid, each team can subscribe through its own handler. One path may call an Azure function. Another may start a logic app, a third may send a web hook to a system outside Azure, if that system belongs in the approved integration design. The same pattern applies to telemetry events, but you need to be selective. You might publish a filtered telemetry event when a gateway reports a defined machine condition. Several independent systems can then receive it. A maintenance application may record the condition. A workflow may open a review task, a data quality service may check whether related signals also arrived. That doesn't mean event grid should receive every sensor message simply because it can publish telemetry events. A fan out path has a purpose when several systems need a prompt notice. It becomes noise when routine measurements go everywhere and every team has to decide which ones matter. The scale difference gives event grid a clear place in large integration designs. IoT Hub message routing on paid tiers supports a limited set of custom endpoints, while event grid supports up to 500 endpoints per IoT Hub. That wider subscriber model helps when separate applications, teams and external services need their own event subscriptions. Still, more endpoints don't create more meaning. A larger fan out capability solves distribution. It doesn't tell you whether a device disconnect affects production, whether a temperature value needs action, or whether a workflow should change a plan. Those decisions still depend on the event contract, the current state of the equipment and context from systems such as the MES and asset model. So use the integration for what it does well. Publish clear device and telemetry related notices to systems that need to react independently. Keep the message shape deliberate. Device identity consistent and let the subscriber receive a notice that starts work rather than pretending it received a complete account of the factory. More subscribers solve one problem. They don't solve every problem. Event grid does not promise order. There is one constraint you need to design around before you use event grid for an industrial workflow. Event grid doesn't guarantee that subscribers receive events in the order they occurred. That's not an edge case. It changes while an event handler is allowed to conclude. Picture a gateway that briefly loses its cloud connection, reconnects, then loses it again while the plant network team works through a switch issue. IoT Hub may publish connection and disconnection events for those state changes. A subscriber could receive them in an awkward sequence. It might see a connected event after a later disconnected event or receive one notice after a delay while newer notices have already arrived. If the handler treats each incoming event as the final truth it can create the wrong operational state. You can end up with a support record that says the gateway is online when it has already dropped again. Or you can send an escalation to a line team after the connection recovered. Either outcome means event grid failed. The handler assumed more than the delivery model promised. So the right pattern is simple. Treat the event as a prompt to check. A device disconnected event can start in Azure Function. That function reads the current device state from the device registry or checks the relevant device twin then compares the current state with the event it received. If the device already reconnects, the function may record the short disruption and close the technical check. If the device still appears unavailable, it can raise the issue through the support path your plant has defined. The event starts the investigation. It doesn't settle it. This also protects you from duplicate delivery. Event grid uses at least one's delivery, which means a subscriber can receive the same event more than once. Your function or workflow needs a way to recognize that it already created the support case, already updated the asset status or already notified the responsible team. Item potency is the technical word for this. In plain terms, processing the same event twice should not create two tickets, two emails and two conflicting status changes. A good handler stores enough information to make that decision. It may use the event ID as a processed record reference. It may keep the latest known state and timestamp for the device. For life cycle changes such as device creation or deletion, it can inspect the versioning information and current registry state before it changes anything. That might sound like extra work for a simple notification, but it's the work that lets notification stay simple when conditions become messy, which they always do around networks, gateways and real equipment. There's another reason to check current state rather than trust the arrival order. A device event describes a cloud-facing device connection. It does not automatically describe the health of the machine, the control network or the production operation. A gateway may reconnect while its PLC data connection has failed. A gateway may disconnect while the press continues to run locally. And a device-created event may arrive before your onboarding workflow finishes assigning the correct plant, owner and asset relationship. The event tells you where to begin. Your systems of record tell you what to do. For that reason, I design event grid subscribers around a current state check and a clear action boundary. It also receives a notification. It validates the device identity and event type. It checks the latest state from the right source, then it either records, escalates or closes the condition. That approach also keeps your event contracts honest. The notification can say, "A connection state change was reported for this device at this time." It should not claim this production line has stopped, unless another component has checked the machine and MES context required to make that statement. Event grid works very well for this kind of reactive flow. It can tell separate systems that something worth checking occurred. And those systems can act without consuming the entire machine stream. Just don't ask it to rebuild operational history from arrival order. Use it to start the next check. Connection events bring one more manufacturing specific limitation that teams often miss until they try to use them as a source for uptime. The 62nd Connection State Trap. A connection event can help you spot a cloud communication issue. It cannot give you a precise uptime record for a machine. IoT Hub attempts to report device connection state changes, but it reports changes no more often than every 60 seconds. That means a gateway can disconnect, reconnect and disconnect again within that window, while the event stream doesn't show every change in between. You may see several connected events without a matching, disconnected event. That can look strange until you understand the reporting interval. The cloud received state notifications at the times it could report them. It didn't record every movement in the network path. For a factory team, that distinction matters a lot. Imagine an industrial gateway on a press line, loses its Wi-Fi, or wired uplink for 20 seconds during a shift change. The gateway reconnects quickly. It may buffer its telemetry locally and send it later. The press may never stop. Operators may never notice anything. Yet, a cloud support system that treats connection events as machine uptime could record a production disruption that didn't happen. Now reverse the scenario. The gateway remains connected to IoT Hub, but the OPC-UA connection between the gateway and the PLC fails. The cloud sees a connected device. The machine may still run, or it may stop, but either way the gateway can't collect the signals you expected. The cloud connection looks healthy. The data collection isn't, that is why device connection state, data collection health, and machine production state need separate definitions. They're related, but they answer different questions. Device connection state asks whether the IoT client maintained its connection to IoT Hub. Data collection health asks whether the gateway can still read the PLC sensors or edge applications that supply its messages. Production state asks whether the asset is producing, stopped, inset up, starved for material, blocked downstream, or running a planned maintenance task. A single connected flag cannot answer all three. If it could, factories would be much easier places to model, and Excel would finally be out of a job. That hasn't happened. Protocol choice also affects these events. IoT Hub connection and disconnection notifications apply to devices connecting through MQTT or AMQP, including those protocols over web sockets. Devices that only communicate through HTTPS don't trigger those connection state notifications. That doesn't make HTTPS wrong. It just means you shouldn't design a monitoring process that expects connection events from a device that communicates only through HTTPS. The delivery behavior follows the protocol and connection model. Before you build a workflow around disconnect events, ask a few direct questions. Which devices use persistent MQTT or AMQP connections? Which devices batch messages through HTTPS? Does the gateway buffer when the plant network fails? Does it publish a health signal that confirms it can still read the PLC? And which system owns the machine state that production uses? Those answers shape the design more than the name of the Azure service. A better industrial pattern uses connection events as one input into a technical health check. A disconnect notice may tell the support process to inspect the gateway, its last telemetry time and the status of nearby devices. If a whole group disappears together, the likely cause may sit in a network segment or switch. If one gateway drops, while others remain online, the team can narrow the investigation. But don't label the machine as "down yet". For production availability, use machine state from the control layer or M.S. with the reason codes and operational rules your plant already uses. For OT network health, use the monitoring tools and signals that can see the relevant network path. For cloud connectivity, use IoT hub events and message arrival patterns. Each source provides a different part of the operational picture. That separation also helps when an event arrives after the device has already returned. The workflow doesn't need to panic. It can check current cloud state, inspect recent telemetry, and record whether the incident still needs a person. A short cloud gap may matter for data completeness even when it has no effect on output. A connected gateway proves one narrow fact, the gateway can talk to IoT hub. It doesn't prove the machine is healthy, the PLC link works, or the line produced good parts. Device lifecycle events and provisioning workflows. A device lifecycle event often starts before the gateway sends a single useful machine signal. Picture a new gateway being prepared for a packaging cell. Someone registers it in IoT hub, perhaps as part of an automated provisioning process or a controlled engineering handover. That registration can publish a device created event into event grid and the event can start the administrative work that turns a technical device identity into something the plant can support. That work needs ownership. An Azure function might check whether the device ID follows the naming rule for that site in line. It can create a pending asset record, attach the device to an approved support group, and flag the record if the expected machine link doesn't exist yet. A logic app might then create a task for the local OT engineer to confirm the installation and for the security team to check the access process. None of that needs a telemetry stream. It needs a prompt, traceable workflow. The same event can reach more than one subscriber, but each subscriber should own a narrow step. The asset process manages the equipment relationship, the identity process manages access. The service process confirms that someone owns the device after it reaches the plant. If one workflow fails, it shouldn't leave the whole onboarding process as a mystery spread across email threads. That is where event grid fits well. It distributes the notice that a device record changed. Your downstream services then check the details they need and update their own records through defined interfaces. The event doesn't need to contain the whole asset structure. It only needs enough information to identify the device and start the right process. A deletion event deserves the same care. When somebody deletes a device from IoT Hub, that may be planned. A gateway may have reached end of life, move to another plant or been replaced during a line upgrade. It may also be an unexpected change that needs review. A device deleted event can start access cleanup, remove stale monitoring links, and ask the asset owner to confirm whether the physical equipment changed or only its cloud registration. Don't let deletion quietly become housekeeping. If the cloud identity disappears while the gateway still sits beside a running machine, the plant may lose data without anyone noticing until a report turns blank. A deletion workflow can check whether the asset still appears active in the maintenance system, whether its last message arrived recently and whether a replacement device registration follows within the expected change process. The action should match the risk. That doesn't mean every life cycle event needs a human approval. Many checks can run automatically. A function can validate that a new device belongs to an allowed site. It can create a pending record. It can add standard tags or send a configuration request through the control device management path. Human review enters where the workflow changes equipment, ownership, network access, production use, or a record that people rely on during an incident. There's one small but important warning around device created events. The event can include twin data, but Microsoft documents that this twin data starts as default configuration and shouldn't be treated as proof of the device's actual authentication details or other newly created device properties. That means your onboarding workflow should verify the device through the proper device registry or management interface before it trusts those details. It may feel fuzzy, but it avoids a common failure. A workflow reads a creation event, assumes the included twin represents the final device state, then assigns controls or access based on incomplete information. A few minutes later, the device setup changes and the records no longer match. Now the team has two versions of device truth, which is exactly the sort of problem that turns a simple gateway rollout into a week of calls. Treat the lifecycle event as a reliable notice that something changed. Then query the authoritative source for the current state needed by the next step. This is why Spass action-driven workflows belong naturally in event grid. A device gets created, deleted, connected, or disconnected. A focused process receives that notice and performs a defined follow-up. It doesn't need to read thousands of measurements just to learn that a record needs attention. The details of that follow-up still depend on how you filter the message flow because filtering decides where the first piece of logic lives. Filtering. Select the right messages before they spread. Filtering decides where you want the first decision about a message to happen. That sounds like a small conflict choice, but it shapes how much traffic reaches each system, how much code each team writes, and how easily you can explain why a message reached a given destination. For IoT Hub message routing, the question usually starts with the stream itself, which device messages belong in this path. A route can filter using application properties that the Gateway ads, system properties supplied by IoT Hub, fields in the message body, and device twin tags or twin properties. That gives you several ways to separate industrial traffic before it reaches the downstream endpoint. Say a gateway reads signals from several machines online too. It may send production state, energy use, diagnostics, and condition monitoring signals through the same device connection. You don't want to rely on the receiving system to guess which message belongs to which process. Put the useful classification close to the source. The gateway might add a message property that identifies the signal class as energy, production, or diagnostic. It might include an asset ID and a source timestamp in the payload. The device twin may hold a managed tag that identifies the gateway's plant, line, or support domain. IoT Hub routing can then use those fields to send only line two energy messages to an energy stream, while production state messages follow the path built for production analysis. That keeps the first split clear and visible. Body queries can help too, provided your message format stays stable. For example, you may route messages only when a state field indicates a defined operating condition, or only when a payload identifies a particular signal group. But I'd be careful about putting all business logic into a routing query. Routing should make broad traffic decisions. It should not become a hidden rule engine that nobody on the plant side can explain or maintain. Twin tags help when the classification belongs to the managed device, rather than each message. If a gateway always belongs to a given site, a twin tag can avoid repeating that fact in every payload. But if a gateway observes multiple machines or can move between production areas, you need governance around those tags. A tag that says line two, while the gateway now sits on line four, creates a clean route carrying the wrong data. Cleanly wrong still counts as wrong. Event grid filtering answers a different question. Instead of choosing a data path for a stream, it chooses which subscribers should receive a notification. An event grid subscription can filter by event type, by subject, and by fields in the event data. For IoT Hub events, the subject identifies the device path. That lets a subscriber focus on a defined device set, such as gateways from one side, one line, or one naming group. A device support workflow might subscribe only to disconnected events from a group of production gateways. An onboarding service might subscribe only to device created events. A telemetry triggered workflow might filter for messages whose data matches a narrow condition that its owner has agreed to handle. The difference matters. IoT Hub root filtering decides which operational messages should enter this data path. Event grid subscription filtering decides which notices should this handler receive. Both reduce noise, they do different jobs. If you use event grid filters as the main way to segment continuous machine data, each subscriber can end up with its own version of what counts as relevant. One handler filters by device prefix, another filters by a payload field. A third ignores a message property and recreates the logic in code. Over time, the architecture spreads basic data selection across too many places. That makes changes harder than they need to be. A shared telemetry root should carry an explicit, governed class of data. Event subscribers should receive a focused signal that starts a specific reaction. That boundary lets the data team own stream rules while the workflow team owns response rules, without either group quietly rewriting the other groups logic. Filtering also needs a versioning plan. Payloads change. New signal types appear. A gateway firmware update may rename a field, add a nested structure, or change how it reports a state. If roots and subscriptions depend on those fields, test the change against the whole path before it reaches production. Otherwise, a message can still reach IoT Hub successfully while disappearing from the root or subscription that matters. From the device side, everything looks fine. From the business side, the data is vanished. And filtering cannot repair missing meaning. It can separate line 2 energy telemetry from press diagnostics. It cannot tell you whether a high energy reading came during normal production, a setup run, a maintenance task, or an abnormal condition. That context has to come from somewhere else. Context comes from ERP, MES, and the asset model. A device ID tells you where a message came from. It doesn't tell you what the message means to production. That gap appears the moment somebody asks a practical question. A gateway reports that a press has stopped sending data. Is that press and production? Is it being set up? Is it underplanned maintenance? Does it run an order that another machine can take over? Or is it the only resource qualified for that operation? You won't find those answers in a device ID. The MES, your manufacturing execution system, supplies much of the shop floor context. It can connect an asset signal to an active operation, a work order, a recipe or routing step, a shift, and the production status recorded by the people and systems running the line. That link turns a raw state such as stopped into something more useful. For example, the same machine state may mean very different things depending on the mass record. A stopped press during a planned die-changes expected. A stopped press during a high-priority production order might need attention. A stopped press after the order completed may not affect output at all. The sensor value didn't change. The context changed. ERP brings another layer. It usually knows the demand side of the story. Customer commitments, material availability, order dates, inventory positions, and the wider plan. If a production issue lasts long enough to threaten output, ERP context helps the business understand where the pressure lands, but ERP shouldn't pretend to know the current machine condition just because it contains a production order. Its plan describes intent. The MES and the machine layer describe execution. Those systems need to connect, but they shouldn't override each other's role. Think about a planner looking at a late order. ERP may show a promised delivery date and the order quantity. MES may show that the operation started, paused, or completed only in part. Telemetry may show rising vibration before a stop. The asset model may show which other machines can perform the same process. Only together do those facts support a sound decision. The asset model provides the physical structure that links technical devices to equipment people recognize. A gateway belongs to a network zone. It reads one or more PLCs. Those PLCs relate to machines. Machines sit in cells, lines, departments, and sites. Without that model, every downstream system ends up rebuilding its own mapping table. One team calls the asset press 12. Another knows the gateway is GW North-07. The MES uses a resource code. The maintenance system uses a different equipment number. Then a simple question such as, "Which line lost data?" becomes a joint problem with human consequences. That's not unusual. It's just expensive confusion. In practical terms, the asset model should give you stable relationships. This device reports for this gateway. This gateway collects from this machine. This machine belongs to this line. This line can produce these product families under these approved process rules. You don't need to put every relationship into IoT Hub. You do need one governed place where those relationships can be maintained and consumed. For some manufacturers, a structured asset register plus MES master data is enough. Others need a digital twin or a knowledge graph because they need to reason across changing relationships. Assets, sensors, processes, materials, workers, quality checks, and production constraints. A knowledge graph sounds like a big idea, but the plain version is simple. It records how things relate. Instead of storing a machine as one isolated record, it can represent that the machine uses a certain tool, runs a certain process, receives data from a certain gateway, and supports a defined set of operations. When something changes, systems can follow those links rather than asking people to remember them. That's useful when the question moves beyond technical support. A device disconnected notice may point to a gateway. The asset model can identify the machine in line. MES can show the active work order and current operation. ERP can show whether delayed output affects downstream demand. The event still doesn't decide anything by itself, but it reaches a system that can ask better questions. And that's the point. Integration isn't only about moving messages between Azure services it's about connecting the dots between IT and OT without turning every raw signal into a false business conclusion. So let's return to the press line. The gateway goes offline while a work order is active, and now the architecture has to separate a loss of cloud visibility from an actual production problem. scenario, the gateway goes offline during a work order. Let's make the failure concrete. Press 12 is halfway through an active work order. The operator has the press running, the MES shows the operation is active, and the gateway sends normal process data into IoT Hub. Then the gateway loses its connection to the cloud. An event grid subscription receives a device disconnected event and starts a support workflow. That's a sensible first move. The workflow creates an investigation record, adds the device ID, the event time, and the support owner for that production area. It should not stop the press, the cloud lost contact with the gateway. That is all the event proves. The press may still run under local PLC control, the operator may still produce parts, or the gateway may have failed in a way that also remove data collection from the line while production continues normally. Those are different situations. The first check should focus on the gateway and the telemetry path. A function triggered by the event can inspect when IoT Hub last received a valid message from that gateway. It can compare the last source timestamp with the cloud receipt time and look for a sudden gap in production telemetry. That gives the support team a better starting point. If the last messages showed press 12 in a running state and telemetry stops abruptly, the plant has lost visibility after that point. It has not yet proved that the press stopped. If Bufford messages arrive when the gateway reconnects, they may fill part of the timeline later, and the incident becomes a data completeness issue rather than a production interruption. That distinction saves a lot of bad escalation. Now bring in the MS. The MES can confirm whether the operation remained active, whether the operator recorded a stop, whether parts continued to count, and whether a reason code appeared. In some plants, the MES receives production data through another local path. In others, the operator records the change. Either way, the MES helps separate a cloud connection issue from the execution state of the work order. Suppose the MES still records cycles and the operator has no stop reason. The press likely kept running. The immediate task becomes checking the gateway, the OT network path, and whether missing telemetry will affect traceability or condition analysis. Suppose instead the MES shows the operation paused and the operator records an equipment fault. Now the event grid notification and the telemetry gap point to what a real operational issue. But the plant still needs more than a disconnect event before changing the production plan. They need duration. They need to know whether the press has stopped for a few minutes, whether maintenance can restore it, and whether the operation can move to another approved resource. The production impact comes after the operational facts, not from the first cloud notification. That order of reasoning matters. A planner may see that the work order sits on press 12. ERP can show demand dates and downstream commitments. But neither system should assume that every gateway disconnect threatens delivery. If the press continues locally, re-planning creates churn for no operational reason. If the press truly stopped, waiting for a dashboard refresh may waste time. The architecture needs both speed and restraint. Event grid provides the fast signal that starts the investigation. IoT Hub telemetry provides the last known machine facts and potentially the backfilled record after reconnection. MES confirms what production actually did. The asset model identifies the affected machine and line. Only then can a planner judge whether the work order faces a real constraint. Consider a more awkward case. The gateway reconnects after 10 minutes and event grid sends a connected notice. That does not close the production question either. The function can confirm that cloud connectivity returned, but the team still needs to check whether the gateway resumed PL-series, whether buffer data arrived and whether the production operation continued. A green connection status can end a network incident while leaving a data incident open. This is why I prefer an investigation workflow with clear states. First, cloud connection lost, then telemetry path checked, then production state confirmed through MES or local control data. Finally, impact assessed if the machine actually stopped or if data lost threatens a quality or traceability record. Each state has an owner and a source of evidence that may sound more deliberate than firing off an alert and assuming someone sorts it out. But a work order doesn't care that an Azure event arrived quickly. It cares whether the press produced the required parts, whether the process stayed within limits and whether the plant can still meet the next commitment. The same incident makes the architectural boundary clear. Neither IoT have rooting nor event grid replaces the other because one preserves the operational record while the other starts the right response. The wrong design, event grid as a telemetry bus. A common mistake starts with a reasonable idea. A machine sends data, something receives it, and a function reacts. That can sound like an event driven architecture. But if every temperature reading, cycle count, vibration sample, and current value enters event grid, you've turned a notification path into your main telemetry bus. The architecture might work at first, then normal production begins. Picture a gateway sending frequent readings from a press line. Every message reaches event grid. Several subscriptions react. One function checks temperature, another writes a record. A logic app sends something onward. A third handler tries to detect whether the machine is running or stopped. Soon, routine sensor traffic starts thousands of tiny workflows that never needed to exist. A temperature reading is not an incident. Most measurements only become interesting when you compare them across time, against the limit, or with other signals. A single vibration value rarely tells maintenance what to do. The pattern over time may tell them something that requires a stream-oriented process that can read the sequence, apply rules consistently, and retain enough history to inspect later. When event grid becomes the main route for that work, every subscriber starts recreating stream processing in its own handler. One team stores a partial history in a database, another keeps a small cache. A third assumes that the latest event represents current machine state. Before long, each process has its own version of the telemetry story. That creates drift event grid can deliver a telemetry event more than once, and it doesn't promise delivery order. A function that receives a reading can't safely assume it arrived after the last reading had processed. If it updates a current state record without checking timestamps and message identity, an older measurement can override a newer one. For an isolated alert, that may be acceptable if the handler checks current state before it acts. For continuous telemetry, it quickly becomes awkward. You're asking every event handler to solve later-arrivals, duplicates, sequence gaps, replay and state reconstruction independently. That's a lot of accidental engineering. There's also an operational problem. A team later asks a normal question, what did the press do during the hour before a quality deviation? If the design only pushed messages through functions and workflows, where is the complete record? Which handler stored every message? Did it store source time, cloud receipt time message properties and the original payload? Can someone replay the data with a revised rule? Often nobody can answer with confidence. The system reacted in the moment, but it didn't preserve evidence. This is where the word event creates confusion. In software, a telemetry message can technically count as an event because it reports something that happened. But architecture needs more precision than vocabulary. A repeated measurement belongs to a flow where consumers can process it over time. A discrete change that starts a task belongs to a notification path. Those are different delivery needs, sending all telemetry through Event Grid also spreads ownership in an unhelpful way. The maintenance team builds one subscription. The quality team builds another. The energy team creates a third. Each one filters slightly differently, handles errors differently, and retains different fields. Nobody owns the shared operational record. Then a gateway payload changes, maybe a field changes name, a unit changes, or a source time stamp moves. Several workflows fail in different ways. Some keep running, but read the wrong field. Others quietly stop receiving the events they expected. The factory still produces. The cloud pipeline slowly loses its grip on what production is doing. That's not a criticism of Event Grid. It's the case of using the right service for the wrong job. Event Grid works well when a defined event should prompt independent systems to act. A condition monitoring process can inspect a telemetry stream, detect a condition that meets a rule, and publish a clear event such as this asset needs maintenance review. Event Grid can then distribute that notice to the work order process, the support workflow, and any other approved subscriber. That event carries a decision point. The raw vibration samples that led to the decision should remain in the telemetry path where they can support later review. The event tells people and systems to respond. The telemetry explains why. Keep those roles separate, and the design stays easier to test, operate, and explain. Push every reading through a notification fabric and your functions become a collection of improvised stream processes, wearing different names. The reverse mistake causes trouble too, treating every simple notification as if it belongs in a heavy telemetry pipeline. The other wrong design. IoT Hub rooting for every notification. The opposite mistake looks more disciplined at first. A team decides every message should go through IoT Hub rooting because all device-related information already enters IoT Hub. That includes telemetry, but also simple lifecycle notices that should start a quick business or support action. Technically, you can route many non-telemetry events. The issue isn't whether it's possible. The issue is what every recipient now has to build just to react to a simple change. Take a new gateway registration. A device identity appears in IoT Hub and someone needs to verify the asset owner, site assignment, and network zone. That's a sparse event. It happens once during onboarding, not every few seconds across a shift. If you route it into a data pipeline, the receiving team may need a consumer that reads from an event hub, processes the record, tracks its offset, handles retries, and then starts the onboarding task. That's a lot of plumbing for a notification that really means a new device needs review. The same pattern appears with device deletion. A security or asset team may need to know quickly that a cloud identity disappeared. They don't need to consume a continuous machine stream and wait until their consumer reaches that one lifecycle record. They need a focused notice that starts a defined check. Routing can still deliver the message, but it may put the wrong burden on the downstream system. Each team then builds its own consumer logic. One group pulls or reads a stream for new device registrations. Another reads the same or a separate path for disconnects. A third team builds a small service to detect deletion events. Soon, basic workflow triggers sit inside stream consumers that were built mainly because the data arrived through a telemetry-oriented route that adds delay and ownership confusion. A stream consumer works well when it needs a sequence of records and can process them at its own pace. A provisioning workflow usually wants a prompt trigger. A support escalation often wants a direct notice. An external service may only need a webhook call after a device state change, forcing each of those use cases through a shared data path can turn a simple response into a chain of readers, checkpoints, queues, and custom rules. None of those pieces are wrong. They just don't belong in every workflow. Think about the person who owns the device on boarding process. They should be able to define which device created events matter, where they go, and what follows. They shouldn't need to understand the consumer group design for production telemetry merely to create an asset review task that separation helps teams move without stepping on each other's work. IoT Hub message routing also has a finite number of custom endpoints. On paid IoT Hub tiers, the documented limit is 10 custom endpoints per hub, though one endpoint can support multiple routes. For a focused telemetry architecture that can work well, but if every department, workflow and external application asks for its own direct route, the endpoint limit becomes an architecture discussion sooner than expected. At that point teams often add more bridges, a routed message enters an event hub. A custom worker reads it, the worker republishes it somewhere else, another service filters it, then a workflow starts. You can build that chain, but it deserves a question. Are we preserving an operational record, or are we only trying to tell someone that a device changed state? If the answer is notification, use a notification pattern. This doesn't mean lifecycle events should never enter a data path. A central operations team may retain those events for audit, diagnostics, or device fleet analysis. That can be useful. A device connection history can support an investigation. Device creation and deletion records can support governance, but retaining a record and distributing a prompt of separate needs. You may route lifecycle data for history while event grid publishes the same kind of change to the systems that need to react. One path lets you analyze patterns later. The other starts the work now. Those paths can share identity and correlation details without forcing every consumer to behave like a stream processor. That becomes more relevant as an industrial Azure estate grows. Analytics teams need stable data paths. OT support teams need technical alerts, asset teams need controlled onboarding, business workflows need their own boundaries. A single route for everything can feel tidy in the first workshop then become a shared bottleneck once each group starts adding its own requirements. IoT Hub routing remains useful. It just isn't the only tool that belongs after a device message reaches Azure. The cleaner pattern separates the paths by the decision they support. One plane carries operational data while another distributes the signals that ask people and systems to respond. The combined pattern, data plane and control plane, the cleaner architecture starts by giving each path a clear job. IoT Hub sits at the edge to cloud boundary, where gateways and devices authenticate, send machine data, report manage state, and where the design calls for it, receive controlled messages from the cloud. That device boundary matters because OT and cloud systems have different concerns. A gateway may talk to older PLCs, normalized tag names, buffer data during a network break, and send a defined message contract when the connection returns. While IoT Hub manages the cloud facing identity and intake path. From there, think in two planes, the data plane carries the operational record. It moves telemetry in other records, where sequence, retention, and later analysis matter. IoT Hub message routing selects the records that belong in that plane and sends them to stream or storage paths built for the consumers that need them. Those consumers may include a stream process, a raw archive, or an operational data service. They don't all need to run at the same speed and they don't all ask the same questions. What they share is a need for dependable production facts rather than a one-time prompt. The control plane handles a different kind of traffic. It distributes notices about device lifecycle changes or carefully defined conditions that need a response. Event grid sits well in that path because of support workflow, an asset process, and a security check can each subscribe without becoming part of the telemetry processing chain. This doesn't mean control plane equals machine control. That phrase can cause trouble in manufacturing because a cloud workflow should not silently take authority over equipment just because it received an event. In this architecture, control plane means coordination of digital processes, opening an investigation, checking ownership, confirming a data path or asking a responsible person to act. Physical control remains subject to the rules, safeguards and local systems that govern the equipment. The two planes can use the same device identity without becoming the same pipeline. A gateway called plant-appress-12 should mean the same technical device across both paths. Its messages should carry consistent identifiers. Its asset relationship should point to the same equipment record and the people responsible for it should not have to guess whether a notification refers to the gateway, the PLC, or the press. Naming sounds boring until an incident starts. If one path uses a device ID, another uses a local asset code and a third uses a hostname from an old network sheet. The automation may work perfectly while the support team spends 20 minutes working out which physical thing actually needs attention. Shared identity rules remove that kind of avoidable delay. The asset model also needs to cross both paths. A data consumer may need to know that a reading belongs to press 12. A workflow handler may need to know that the same device sits online too and belongs to a defined support group. Neither IoT Hub nor Event Grid creates those business relationships for you. They move information through the architecture, your model supplies the meaning. That shared context also gives you a clean boundary between teams. The analytics team can own how telemetry enters the data plane, how long it remains available, and how it becomes usable production data. The workflow team can own who receives a notice, what checks happen first, and when an issue reaches a person. Both teams rely on common contracts for device identity, timestamps, message classes, and asset references. They don't need to edit each other's pipelines for every change. Without that separation, a new maintenance workflow can create risk for production analytics or a data model change can quietly break a support process that somebody built six months ago. Coupling like that rarely shows up in a first architecture sketch. It appears when the plant adds another line, another gateway type, or another team asking for access, a clear split keeps the growth manageable. There will still be cases where the planes meet. A stream process may detect a condition and publish a focused event for action. A workflow may receive a disconnect notice and query recent telemetry to assess data loss. That's healthy. The connection happens through an explicit contract not because every raw message travels everywhere, so the architecture becomes easier to reason about. The data plane preserves what happened, the control plane coordinates who needs to respond, both begin with connected equipment and both need the same factory context, but neither should impersonate the other. Once that data plane reaches Microsoft, Fabric and Power BI another boundary appears. Reporting can describe production. It doesn't automatically decide what production should do next. From telemetry to Fabric and Power BI. Once telemetry reaches the data plane, Microsoft Fabric can become part of a plant path from machine signals to production analysis. But Fabric shouldn't become the first place where raw, shop floor messages are asked to explain the factory. The source data still needs structure. A gateway may send a cycle count, a temperature, a run state, and an energy reading. Those messages can land in a raw layer where you preserve the original record, its source timestamp, its device identity, and the time as you received it. That record matters when someone later asks whether a number changed because the machine changed. The gateway buffer data or transformation rule changed. Raw telemetry is evidence. It isn't yet a production fact. The next layer turns signals into records that people can use. A run state message can link to a defined machine state. A cycle count can become output only when the logic accounts for resets, rejected parts, and the production context that explains which order the machine ran. Energy data can link to an asset in a time period without pretending that every watt belongs to a good part. That work needs a governed model. In Fabric, you might bring together prepared telemetry with MES events, quality records, and asset reference data. The result shouldn't just be one large table of timestamps and values. It should give each record a clear meaning, which asset produced it, which production period it belongs to, what source supplied it, and which business rules shaped it. Otherwise, Power BI can produce a very clean report from a very confused foundation. And we've all seen that movie. Think about downtime. A device may stop sending a run signal, but the MES may record a planned change over. The operator may enter a material shortage, maintenance may record a fault. If the report uses only the device stream, it can turn several different causes into one generic gap. That may look like real-time visibility. It isn't useful visibility. A better model keeps the machine signal and the MES reason code as separate facts, then connects them through time, asset, operation, and work order context. The report can show where they agree, where they differ, and where someone needs to investigate. It doesn't force the sensor data to claim knowledge it never had. OEE or overall equipment effectiveness is a good example. People often want to calculate it straight from counters and state tags because the formula looks simple. But OEE depends on how the plant defines plant production time, availability losses, performance losses, quality losses, and the reasons behind them. A machine counter can support that calculation. It can't define those rules on its own. If the MES treats a scheduled cleaning cycle as planned time, while the machine data model treats it as downtime, the report will create an argument before it creates insight. The answer isn't to pick whichever source produces the better number. The answer is, to agree on the production definition, record the source facts, and apply the rule openly in the curated model. That is where fabric can help connect the dots between IT and OT. It can bring data from separate systems into a common analytical path while the model keeps track of which system