Conditions
The per-trigger condition fields and how the automation builder maps them.
A condition narrows when a trigger fires. Each trigger kind (except manual) has its own small set of condition fields — there is no general-purpose rule language to write; the automation builder shows exactly the fields that apply to the trigger kind you picked.
Condition fields by trigger
| Trigger | Fields |
|---|---|
| Manual | none |
| Research completed | scoreThreshold (optional, 0–100) |
| Score crossed threshold | scoreThreshold (required, 0–100), direction (above / below) |
| Stage dwell exceeded | dwellDays (required, positive integer), stageId (optional) |
| Signal event received | signalKind (optional — funding, leadership_change, press, m_and_a, layoff, product_launch, other) |
| No activity for N days | days (required, positive integer) |
Fields left blank behave as "match anything for this field" — for example, an empty score threshold on "Research completed" fires the automation for every completed research run, not just high-scoring ones.
How this is stored
The automation builder writes these fields into Automation.triggerJson alongside the trigger kind, e.g.:
{ "kind": "score_crossed", "scoreThreshold": 70, "direction": "above" }
A manual trigger stores just:
{ "type": "manual" }
You don't need to hand-author this JSON — the builder's per-kind fields do it for you. The raw shape is documented here for reference if you're troubleshooting an automation that isn't firing as expected.