Guide / How the automation graph is built

How the automation graph is built

The "automation editor" is a single canvas where you drag "squares" (nodes) and connect them with wires (edges). Every app has one graph that holds all the automations for every screen.

The three kinds of squares

Event
A starting point. It has exactly one output and no input - nothing can "feed into" an event, it's always the start of the chain. Full detail in the "Events" chapter.
Condition
One input, and two outputs: "yes" and "no". The flow continues only on the branch that matches. Full detail in the "Conditions" chapter.
Action
One input and one output - except for "Send push notification", which gets an extra output for every notification button you add to it. Full detail in the "Actions" chapter.

Wiring rules

  • From a given output you can lead to only one place - wiring something new from the same output simply replaces (moves) the previous wire, it doesn't add another branch.
  • Execution starts at an event square and moves wire by wire, running conditions and actions in order, until it "falls off" the graph (no more wire) or reaches a square it already visited in that same run (this guards against an infinite loop).
  • There's no enforcement of required fields on save - you can save an action square with empty fields; at runtime the action simply "does nothing" silently (e.g. a dbSet with no collection/key). That's why it's important to manually check against the "Required vs. recommended" chapter.
How this actually runs in the published app

The graph isn't a "daemon" running in the background - it's really a collection of ordinary event listeners (click, scrolled into view, connected/disconnected from the internet, a WebSocket message, a timer, etc.). The moment one of them fires in the visitor's browser, the engine simply walks wire by wire from that square onward.