Skip to main content
The Event Orchestrator evaluates check results from upstream nodes and routes the workflow to the appropriate action: create a new event, update an existing one, close an event, or do nothing.

​
When to use

Place this node after your check nodes. It reads the checks results and manages event state so your workflow correctly handles the full event lifecycle — from detection to resolution.

​
How it works

The orchestrator maintains event state in the state machine’s Redis store. On each execution, it:
  1. Reads the checks object from the input (set by upstream check nodes)
  2. Evaluates whether conditions are met (using AND or OR logic across all checks)
  3. Looks up the current event state for this scope
  4. Routes to the appropriate output based on conditions + event state

​
Routing logic

Conditions met?Active event?OutputDescription
YesNoCreate EventConditions are met for the first time — create a new event
YesYesUpdate EventConditions still met with an active event — optionally update it
NoNoNo ActionConditions not met and no event — nothing to do
NoYesClose EventConditions no longer met but event exists — close it

​
Outputs

The node has four outputs, one for each routing decision:
OutputIndexDescription
Create Event0Wire this to your event creation logic (Event Manager, image capture, etc.)
No Action1Typically left unwired — nothing needs to happen
Update Event2Wire this if you want to update events while conditions persist
Close Event3Wire this to your Event Manager in close mode

​
Configuration

ParameterTypeDefaultDescription
Scope TypeSelecttrackEntity that events are scoped to: track, zone, device, or site
Scope ExpressionExpression={{$json.track_state.track_id}}Expression to extract the scope ID from the input data
Logic OperatorSelectANDHow to combine multiple checks: AND (all must pass) or OR (at least one)

​
Advanced options

ParameterTypeDefaultDescription
Auto Event Closure (Hours)Number24Maximum event duration before automatic closure. Set to 0 to disable.
Scope Cooldown (Hours)Number0Cooldown period after closing before a new event can be created for the same scope
Debug ModeBooleanfalseEnable verbose logging

​
Scope types

The scope determines how events are grouped:
ScopeUse caseExample
trackOne event per tracked objectObstruction detection — each vehicle gets its own event
zoneOne event per zoneCongestion — one event per zone regardless of which tracks are in it
deviceOne event per cameraCamera-level alerting
siteOne event per siteSite-wide incident tracking

​
Output data

The orchestrator adds an eventOrchestrator object to the output: 
{
  "track_state": { ... },
  "checks": { ... },
  "eventOrchestrator": {
    "action": "create_event",
    "scope": "019bb7ea-4050-...",
    "scope_type": "track",
    "global_event_id": null,
    "event_start_time": null
  }
}
On the close output, global_event_id contains the Worlds event ID to close, and event_start_time is when the event was created (useful for calculating duration).

​
Credentials

No credentials required. The orchestrator communicates with the state machine directly.

​
Example

In the Streaming Track State guide, the orchestrator:
  • Uses track scope (one event per tracked object)
  • Reads the Type I check results
  • Routes to Create Event on first detection → captures image, creates event, generates GIF, sends email
  • Routes to Close Event when the object moves away → closes the event with duration metadata