Trigger node · 2.9 in the design proposal · added 2026-07-02 per owner decision

Triggers

Start a BizFirst workflow automatically when a new transaction lands on a watched Accumulate account — a different kind of node from the other eight resources on this site.

1 operation MVP · owner-set 1s poll interval

Not one of the "8 resources" — a different node shape entirely

The design proposal's own Quick Facts table counts 8 resources (Identity through Utility) and lists Triggers separately. That's not an oversight: unlike every resource above, which implements INodeExecutor, a trigger implements ITriggerNodeExecutor and returns TriggerNodeResult { HasNewItems, Items, ErrorMessage }, following the established pattern already used by email-imap-trigger. It's cron/interval-scheduled polling, not a real push subscription. This site gives it a full page as the ninth building block because a workflow author reasoning about "what can this node do" needs to see it alongside the other eight — but architecturally, it's its own category.

Operations

Code	Operation	Maps to	Why a workflow author wants it	Priority
TRIG01	Watch Account for New Transactions	Poll QX01/QX02 (V2 `query-tx` / `query-tx-history`) on a 1-second interval	Start a workflow automatically when a new transaction lands on a watched account — e.g. "a payment arrived"	MVP

How it works — the poll loop

TRIG01 — one poll per second, per workflow instance using the trigger

sequenceDiagram
  loop every 1 second
    participant TRIG as TRIG01 poll cycle
    participant NET as Accumulate Network
    participant WF as BizFirst Workflow

    TRIG->>NET: QX01/QX02 query-tx / query-tx-history
on watched account
    NET-->>TRIG: latest transaction state
    alt new transaction found
      TRIG->>WF: TriggerNodeResult { HasNewItems: true, Items }
      WF->>WF: workflow instance starts
    else nothing new
      TRIG->>TRIG: TriggerNodeResult { HasNewItems: false }
    end
  end

Implementation note — not a decision to relitigate, but a real operational flag

A 1-second interval is aggressive relative to Accumulate's synthetic-transaction settlement delay (see SmartSigner and 004.References/AboutAccumulate.md §1) — a newly-submitted transaction's cross-chain effects may not be visible that quickly, so most 1-second polls will find nothing new. It also means one poll call per second, per workflow instance using this trigger, which is worth keeping in mind for API rate limits and node load at scale — a dedup/backoff strategy, if needed, is a Phase 2 concern, not part of this design decision. The interval itself is fixed by owner decision, not left as a per-workflow configurable default; if per-workflow tuning is wanted later, that's a follow-up, not implied by this decision.

Business use case — reactive automation on incoming payments

From 001.BusinessIdeas/README.md §2.5

TRIG01 lets a workflow start when a transaction lands on a watched account, rather than only ever being the thing that sends one — e.g. "start the fulfillment workflow when a customer's payment arrives," or "notify finance when a disbursement account receives an unexpected deposit." The scalability caveat above is called out directly in the business-ideas document too, not just the design proposal — worth being direct about it rather than presenting TRIG01 as a free lunch.