Skip to main content
A Signal<T> represents a value that Automate.ax materializes during execution. Triggers and actions return signals while the automation is still planning.
Signals aren’t promises. Don’t await them.

​
Operator families

Dependency and structure operators such as dependentOn, withPrerequisites, scope, and group support every family. This distinction matters most for merge and race: merge accepts independent occurrence streams, while race chooses among alternatives that already share an activation boundary.

​
Planning declares the work

Automate.ax traverses an automation synchronously to register triggers, actions, and coordination. Property access and pure transforms describe how to derive values later.
The transform doesn’t run during planning. It runs after the email subject materializes. Use property access, transform, and t to derive action inputs.

​
Dependencies control readiness

Line order doesn’t serialize actions. A declaration waits for the signals in its inputs and prerequisites.
Archiving waits for labeled; it doesn’t wait for starred. Use dependentOn to add dependencies to one value or withPrerequisites to apply them to a synchronous declaration section. An action accepts a compatible signal as its complete input or at any nested plain-object or array node. Passing the signal creates the durable dependency.

​
Contexts identify occurrences

Each trigger occurrence starts a root context. Actions normally run in the closest context boundary containing their complete dependency chain. Cross-context operators create child boundaries:
  • merge emits each occurrence from independent input streams in its own child.
  • correlate joins selected keyed occurrences from independent roots.
  • collect, funnel, and window create a child from a batch or burst.
  • once, take, and rateLimit bound admission per partition.
  • each creates a child for each array item.
  • race creates a child for its selected result.
  • serialize admits one occurrence-scoped work region at a time per partition.
  • concurrent admits a fixed number of active regions per partition.
A literal action can infer its context when the automation has one possible root. When several visible or hidden roots are possible, give it a signal input or wrap it with withPrerequisites. Action context placement covers the planning rules.

​
Partitions coordinate repeated occurrences

Cross-context batching and timing need an explicit partition:
  • keyBy isolates occurrences by a customer, record, conversation, or other encoded key.
  • globally places every occurrence in one shared partition.
Value-preserving operators can retain the annotation. Arbitrary derivations and multi-input selections can return an ordinary signal, which must be keyed again before another cross-context operation. Coordinate occurrences explains the choice.

​
Signals emit, fail, or close

A signal terminates once:
  • Succeeded: emitted a value. Returning null or undefined from an action still succeeds.
  • Failed: produced an automation error. Dependent actions skip; unrelated work can continue.
  • Closed: produced no value because a route wasn’t selected.
Only errors thrown by an action handler use that action’s retry policy. Input validation, output validation, and synchronous signal evaluation fail immediately. Use outcome to turn every terminal state into a tagged value. Use onSuccess, onFailure, or onClose to declare work for one state.

​
Choose the next operation