Skip to main content

Overview

Triggers is the event-driven runtime behind Reactive CRM flows. A released flow starts with a source event, moves through one or more service nodes, runs actions inside those services, and keeps routing the result payload through the graph.

In this repo's v2 shape, the important loop is:

  1. A service starts and registers its manifest.
  2. The runtime sends flow broadcasts so that service knows which released flows target it.
  3. A registered source can start a flow run.
  4. When the graph reaches a service segment, the manifest's service_sources describe what that segment can receive, while the live ingress target is opened from released flow service-in config reconciled from flow broadcasts.
  5. Actions run inside the service.
  6. The runtime emits CompletionEvent observability events for node progress and outcomes, while the result payload continues through the graph separately.
  7. Terminal failures go to a DLQ instead of disappearing.

That split matters. The observability event is not the action result body. The result payload continues through the graph, while CompletionEvent exists so the runtime can track what happened.

Main surfaces​

Studio​

Use Studio to build and release flows. The cleanest first path is:

source -> service(flow_lab) -> action(parse)

That is a good starting shape, not the whole grammar. In the broader graph, a source can also route into nodes such as condition, rate-limit, mapping, output-topic, or service-in before a service action runs.

If you want to chain actions in the flow_lab example, route through another service segment with an explicit downstream action:

source -> service(flow_lab) -> action(parse) -> service(flow_lab) -> action(wrap)

Services and SDKs​

Services define actions, service_sources, schemas, and routing capabilities in a manifest. Top-level flow sources are registered separately and start the flow. In Studio, the node labeled as a service segment maps to the runtime service-in node kind. In this repo, the cleanest local dummy is flow_lab, which lives in the Go SDK examples and is meant to exercise the full v2 path.

Runtime API and inspection points​

The local runtime exposes useful inspection endpoints while you are learning:

  • GET /api/v2/services/<service> to confirm registration and inspect the current manifest
  • GET /api/v2/flows/<flow_id>/runs to inspect recent runs

You will use both in the first local walkthrough.