--- alias: user-guide-automation-zones tags: - automation tasks description: "Data zones provide context-based segmentation for workflows, facilitating data flow across tasks" --- # Zones Many Data Generator Tasks emit data known as a **zone**, a context-based data structure that groups together every value produced by one specific occurrence of a workflow trigger. Connect IoT workflows run asynchronously: each task's own execution is synchronous, but there is no guarantee about the timing between one task and the next, particularly under high message volume. Without a way to tell which outputs belong to the same occurrence, a task that consumes several inputs together, for example a Log Message task logging two related properties, could combine values produced by different, unrelated occurrences: some already up to date, some not produced yet, and some left over from an occurrence that took longer to process than a more recent one. A zone solves this by tagging every value produced from the same occurrence with the same execution context, so a task consuming multiple correlated values only ever reads values that genuinely belong together. A zone is created automatically whenever one of the tasks listed under [Tasks that Emit Zones](#tasks-that-emit-zones) fires, and every value produced from that point onward, by that task and by whatever it triggers, carries the occurrence's execution context. A few non-trigger tasks can also start a new zone explicitly through an `Emit in new context` setting, for example the [Retrieve Data](core/workflow/actions/task_retrieve.md) task when it reacts to a value stored from outside its own trigger chain. When no zone applies, values run in the `root` context and are not correlated with one another. ## Zones and Control Flow !!! note You do not need to manage zones when working within Control Flow. Control Flow is deterministic: every occurrence of a trigger runs its own **branch**, a private set of task instances created specifically for that occurrence, executed from a Start task through to an End task, and discarded once it finishes. Because no two occurrences ever share the same task instances, there is nothing for a zone to correlate; each branch's data is already isolated by construction, so Control Flow authors never need to configure or reference a zone directly. Data Flow works differently: the tasks placed on the canvas are instantiated once, when the workflow starts, and that same set of task instances stays in place and keeps receiving and processing events for as long as the workflow runs. Because those instances are shared across every occurrence, when the time each task takes to execute varies, for example under high message volume, or when one branch of the flow is slower than another, values produced by different occurrences can reach a shared task out of step with one another. Zones exist to solve exactly this: by tagging every value with the execution context of the occurrence that produced it, a Data Flow task consuming several inputs can tell which of them actually belong together. ## Example Consider a workflow with an [Equipment Event](core/equipment/triggers/task_equipmentevent.md) task listening for a piece of equipment that reports both a `Temperature` and a `Humidity` property together, feeding a [Log Message](core/workflow/actions/task_logmessage.md) task that logs both values. The Log Message task is instantiated once and is shared by every occurrence of the event. Each event occurrence gets its own zone, so the `Temperature` and `Humidity` values read by the shared Log Message task are always the pair produced by that same occurrence, even if the equipment raises two occurrences close together, or one property takes longer to reach Log Message than the other. Without this correlation, a second occurrence arriving quickly could overwrite `Temperature` before `Humidity` from the first occurrence has been processed, and Log Message could end up logging a `Temperature`/`Humidity` pair that never actually occurred together. ## Tasks that Emit Zones ### Core Tasks #### Equipment * [Equipment Event](core/equipment/triggers/task_equipmentevent.md) * [Subscribe In Driver](core/equipment/triggers/task_subscribeindriver.md) ### File Drivers Tasks * [File Change Event](filedrivers/task_filechangeevent.md) * [File Deleted Event](filedrivers/task_filedeletedevent.md) * [New File Event](filedrivers/task_newfileevent.md) ### OIB Tasks * [GateKeeper Board Failed](oib/task_gatekeeperboardfailed.md) * [GateKeeper Board Released](oib/task_gatekeeperboardreleased.md) * [GateKeeper Board Request](oib/task_gatekeeperboardrequest.md) * [GateKeeper Line Configuration Changed](oib/task_gatekeeperlineconfigurationchanged.md) * [GateKeeper Scanner State Changed](oib/task_gatekeeperscannerstatechanged.md) * [Station Event](oib/task_stationevent.md) * [Board Processed](oib/task_boardprocessed.md) * [Setup Center Feeders Placed](oib/task_feedersplaced.md) * [Setup Center Feeders Removed](oib/task_feedersremoved.md) ### SECS/GEM Tasks * [Equipment Alarm](secsgem/task_equipmentalarm.md) * [Map Requested](secsgem/task_maprequested.md) * [Map Updated](secsgem/task_mapupdated.md)