02. Core Concepts

Four words keep coming up while you use eeumsae: workflow · node · edge · execution. Read this page once and the rest of the guide gets much easier.

---

Workflow

One automation. Something like "summarize sales every morning and post it to Slack" is one workflow.

A workflow is nodes connected by edges, and there is one rule it has to obey.

There must be no way back. Following the arrows must never bring you back to where you started. (The technical term is a DAG — a directed acyclic graph.)

A workflow can hold up to 200 nodes.

Node

One box inside a workflow that actually does something. There are six kinds.

Type	What it does	Incoming edges	Outgoing edges
ENTRYPOINT	The start. Wakes the workflow via a webhook or a schedule	0	1 or more
CALL	The worker. External API calls, AI calls, data transforms and sending messages all live here	1	0 or more
CONDITIONAL	A branch. Picks which way to go based on a value	1	2 or more
JOINT	A join. Where split paths meet again	2 or more	0 or more
LOOP_START	Loop start. Processes an array one item at a time	1	1 or more
LOOP_END	Loop end. Collects the loop results	1	0 or more

Two rules here are worth memorizing.

1. There is exactly one ENTRYPOINT. If there are two starts or none, the save is rejected.
2. JOINT is the only node that may take several incoming edges. Every other node must have exactly one. If a path splits and has to meet again, put a JOINT at that spot.

Details: 03. Setting Up Triggers (ENTRYPOINT) · 04. Integration Catalog (CALL) · 06. Flow Control (CONDITIONAL / JOINT / LOOP)

Integration

The part that decides what a CALL node concretely does. On its own a CALL node knows nothing. Only once you name an integration, like integration: llm_chat, does it become "the node that calls AI".

- id: summarize
  name: AI summary
  type: CALL
  integration: llm_chat     # ← this decides what it does
  input:                    # ← fill in what the integration asks for
    apiContract: OPENAI_CHAT
    model: gpt-4o-mini
    apiKey: "${secrets.OPENAI_API_KEY}"
    userPrompt: "Summarize the following in three lines: ..."

Every integration asks for different input fields. The full list is in 04. Integration Catalog.

Edge

A line connecting one node to another. It plays two roles.

1) Deciding execution order

edges:
  - from: trigger
    to: fetch-orders     # once trigger finishes, run fetch-orders

2) Passing values (optional)

Attach request.data to an edge and you can rename the previous node's output into something the next node finds convenient.

edges:
  - from: trigger
    to: send
    request:
      data:
        customerName: "${nodes.trigger.response.body.customerName}"

A value passed this way is read in the next node as ${input.customerName}.

Do I have to use it? No. Referencing it directly in the next node as ${nodes.trigger.response.body.customerName} works exactly the same. Edge mapping is for when you want to arrange things so that "a node only knows the names of the values it needs, and the edge knows where they come from". When you are starting out, direct references are simpler.

Execution

When a trigger fires, one execution is created and the nodes run in order.

An execution as a whole has four states.

State	Meaning
RUNNING	In progress
COMPLETED	Succeeded all the way through
FAILED	Failed partway
CANCELLED	Cancelled

Each individual node has its own state too — PENDING · RUNNING · COMPLETED · FAILED · RETRYING · CANCELLED. Which node stopped and what the values were at that moment is visible in the execution history. → 10. Executions and Monitoring

The definition freezes when an execution starts

The shape of the workflow at the moment the execution starts is saved like a photograph, and that execution follows the photograph to the end. So if you edit a workflow while a long-running execution is in flight, the execution already running is unaffected. Your edits apply from the next execution onward.

---

The whole picture

Here is how everything above fits together, in one diagram.

                     ┌──────────────────────────────────────────┐
   Workspace         │  Connections            Variables        │
   (shared assets)   │  Datasets                                │
                     └──────────────────────────────────────────┘
                                     ↓ workflows draw on these
   ┌───────────────────────────────────────────────────────────┐
   │  Workflow                                                 │
   │                                                           │
   │   [ENTRYPOINT] ──edge──> [CALL] ──edge──> [CALL]          │
   │    webhook/schedule       integration      integration    │
   └───────────────────────────────────────────────────────────┘
                                     ↓ when a trigger wakes it
   ┌───────────────────────────────────────────────────────────┐
   │  Execution (RUNNING → COMPLETED / FAILED)                 │
   │  Each node's input, output and error lands in the history │
   └───────────────────────────────────────────────────────────┘

• Connections: accounts on external services like Slack. They save you from writing tokens into YAML. → Page 07
• Variables: API keys and settings. You read them with ${secrets.KEY} / ${vars.KEY}. → Page 08
• Datasets: tables your workflows read and write. → Page 09

---

Next → 03. Setting Up Triggers