Board automation rules

Board Automation Rules will react to committed process events and perform actions. A rule might notify a team after an item enters review, invoke governed business logic after a transition, or call an external integration.

Planned event selectors

The initial model is expected to select:

one exact transition from status A to status B;
exit from one status;
entry into one status.

Additional Board events can be added later as versioned event contracts.

After commit, through the outbox

The Board mutation and its immutable automation event will be written to the existing outbox in one database transaction. A worker will process the event only after commit.

This boundary has important consequences:

an Automation Rule failure does not roll back an already committed move;
external calls never keep the Board transaction open;
delivery is at least once, so every action requires a durable idempotency key;
transient failures can retry, while exhausted failures remain visible for an administrator to resolve;
one failed rule must not block unrelated Boards or rule runs.

Each run will retain safe diagnostics, attempt state, actor and origin details, and correlation information.

Security and execution identity

Delayed work does not automatically gain unrestricted system authority. Each action type must define whether it runs as the originating actor, a configured service principal, or a narrowly scoped system capability. Authorization and managed-secret access will be checked according to that execution model.

External destinations will receive only explicitly mapped data.

Relationship to Board Statements

A future Automation Rule may use a Board Statement as an additional event filter. The rule will need to distinguish values captured by the committed event from current values read later by a retrying worker. That behavior, the action catalog, ordering, retries, replay, and rule-version handling are still design decisions.

For a rule that must reject a transition, status entry, or status exit before it happens, use Board Constraints instead. Use a status-invariant Constraint when supported Board Item, Board Data, or Target Entity changes must remain valid throughout a status.