Automations

Automations are per-board rules: when something happens (trigger), optionally if conditions match, do something (actions). They run server-side, instantly for UI/agent-triggered events and within ~5 minutes for time-based ones.

Managing rules

Board menu → Automations (workspace ADMIN role required). The dialog offers a template builder for the common recipes:

When a task moves to a column → assign someone
When a task moves to a column → set priority
When a task is created → add a label
When a task's due date passes → post a comment

Each rule shows its run count; rules can be enabled/disabled without deleting them.

Agents can manage rules too (admin-scoped tokens): list_automations, create_automation, set_automation_enabled.

Triggers

Trigger	Fires when	Options
`task.created`	A task is created on the board	—
`task.moved_to_column`	A task lands in a column	restrict to one column
`label.added`	A label is added to a task	restrict to one label
`due.passed`	A task's due date passes (checked every 5 min)	—
`sla.breached`	A ticket's SLA due time passes unresolved	—
`check.failed`	A CI run fails on a PR-linked task	—

Harness lifecycle triggers

A harness run's lifecycle also fires automations. Most act on the run's anchor task (a harness is usually anchored to one Jentrix task), so the same task actions (comment, assign, label, fire webhook, …) apply; a run with no anchor task only supports task-independent actions (create_task and the run-level start_harness_stage_run, below).

Trigger	Fires when
`harness.created`	A harness run is created
`harness.stage_ready`	A stage becomes ready to (re)start
`harness.stage_validated`	A stage passes its review/evidence gate
`harness.stage_committed`	A validated stage crosses the commit boundary
`harness.finding_created`	A review finding is recorded (the rule fires for every finding; the finding's `severity` rides the webhook payload for receivers that want to act only on critical/high)
`harness.blocked`	A run is blocked on an operational exception
`harness.completed`	A run reaches its terminal `COMPLETED` status (the final stage committed)

Actions

Actions run through the same operations core as everything else — full authorization, activity logging, notifications, webhooks, and realtime sync apply. Available actions include assigning a member, setting priority, adding a label, posting a comment, and fire webhook (emits an automation.fired event to the board's outbound webhooks).

Two delivery/harness actions are restricted to specific triggers: start delivery workflow (on check.failed, launches a ci_failure_triage loop bound to the failing PR) and start the next harness stage (start_harness_stage_run, harness triggers only — in practice harness.stage_ready). The harness action is the opt-in way to auto-advance a multi-stage run: when a stage commits, it launches the run's next undone stage, deduped against an already-running stage job and a clean no-op while the run is frozen/cancelled/blocked. It is run-level (it targets the run carried by the event, not the anchor task) and never approves a gate — every human gate still stops for a person. Until an admin enables such a rule, stages advance only via the manual "Start current stage" path.

Execution semantics — what keeps this safe

Rules act as their creator. An automation's actions are attributed to the user who created the rule, with source automation — the activity feed marks them with a via ⚡ automation chip so they're never mistaken for manual actions.
Rules can never trigger rules. For board triggers, automation-sourced events are dropped by the dispatcher before rule matching — a hard loop guard. A rule that moves a task will not fire another rule's task.moved_to_column trigger, ever. For harness triggers the guard is structural: a harness automation's actions are task ops that always run as source: automation (so the board dispatcher drops any re-trigger) and emit no harness event — so a harness automation's own writes never re-fire any rule, even though the harness orchestrator (which is itself source: automation) does fire harness automations.
Malformed rules are skipped, not fatal. Rule definitions are re-validated at execution time; a broken rule logs and skips rather than blocking the pipeline.
Every run is auditable. Each execution increments the rule's run count and writes an AUTOMATION_RAN activity carrying the rule's id and name.

Triggers from agents

Events caused by MCP agents (e.g. an agent creating a task) do fire automations — only automation-sourced events are exempt. If you want an agent-driven workflow that doesn't trip a rule, scope the rule's trigger options (column/label) accordingly.