Skip to content

Trigger vs Data Edges

Flow › Chapter 2 noted in passing: not every arrow in a graph carries data. Some arrows just say "now run". This page makes that real.

So far every edge in your workflow has carried a value. We're going to add an edge that carries nothing — its only job is to control when another node runs.

What you will learn

  • The difference between a data edge and a trigger edge
  • Why you'd ever want an edge that doesn't carry data
  • How dependency ordering works when data and trigger edges mix

A quick refresher

FlowDrop has two edge types (Connecting Nodes):

  • Data edge — connects a node's data output port to another node's data input port. Carries a value. The downstream node waits until that value is ready.
  • Trigger edge — connects to the downstream node's special trigger input port. Carries no value. The downstream node waits until the trigger fires.

Both kinds enforce ordering. The difference is whether a value comes along for the ride.

In the editor, trigger ports are coloured dark gray (see FlowDrop Vocabulary › Ports) so you can tell them apart from typed data ports at a glance.

The setup

You should still have the date workflow from Page 4:

ChatInput ──┐
            ├─▶ PromptTemplate ──▶ ChatOutput
DateTime ──┘

We'll add a Logger that records every time the workflow runs — but with a fixed log message that has nothing to do with the user's name or the time.

Step 1: Add a TextInput and a Logger

  1. Click + and add a Text Input (under Text & Output).
  2. Set its defaultValue to Tutorial workflow ran.
  3. Click + and add a Logger node.

Step 2: Wire data into Logger

Drag from TextInput's text output → Logger's message input.

If you stop here and run the workflow, Logger will fire immediately — TextInput has no upstream dependencies, so its output is ready right away, so Logger has nothing to wait for. The log line could land before, during, or after ChatOutput renders, depending on execution order.

We want Logger to fire only after ChatOutput finishes. That's a timing requirement, not a data requirement.

Step 3: Add a trigger edge

Drag from ChatOutput's trigger output port → Logger's trigger input port.

ChatInput ──┐
            ├─▶ PromptTemplate ──▶ ChatOutput ─┐
DateTime ──┘                                   │ trigger (no data)
                                               ▼
                          TextInput ──data──▶ Logger
                          "Tutorial
                          workflow ran"

Two things meeting at Logger:

  • A data edge from TextInput supplying the message value.
  • A trigger edge from ChatOutput controlling when Logger may run.

Step 4: Test

Save and send a message in the Playground. The chat shows your greeting as before. Now check Reports > Recent log messages (/admin/reports/dblog) — you should see a fresh entry: Tutorial workflow ran, dated just after your message.

Send another message. Another log entry appears.

What changed in dependency rules

Once a trigger edge lands on a node, it takes priority for timing (Execution Dependency Rules):

  • Without the trigger edge: Logger waits only on TextInput → fires almost immediately.
  • With the trigger edge: Logger waits on ChatOutput → fires after the chat is rendered.

The data edge from TextInput still does its job — it supplies the message value — but it no longer controls when Logger runs.

This is the rule in plain words:

A trigger edge says "wait for this." A data edge says "here's a value." A node can have both, and the trigger wins on timing.

Why this matters

Trigger edges show up whenever you want to sequence things that don't share data:

  • "After the user gets their answer, log it for analytics" — analytics run after user output, but the log message is unrelated to user output.
  • "Run cleanup once everything else has finished" — cleanup doesn't need any data from the prior nodes, just their completion.
  • "After this branch fires, do X" — gateway branches (Page 6) emit trigger edges.

That last one is where trigger edges are most common, which is why they sit next to gateway nodes in the toolbox. We'll meet them in their natural habitat next.

Next

Branching with Gateways → — split execution into multiple paths based on a condition.