Note

A sticky note on the canvas. Use it to label a section ('after-hours branch'), explain a tricky decision to your future self, or as a junction where sever…

What it does

Does nothing at runtime. The worker enters the node, performs no side-effect, and the flow doesn't advance until an external event arrives. In practice this makes noop a routing-only placeholder: a labelled junction on the canvas that incoming edges can target and outgoing edges can fan out from. The node's title and notes fields exist purely for the editor — the runtime never reads them. Think of it as a sticky note attached to the wire diagram of your flow.

Because the node has no built-in transition (it doesn't auto-advance, doesn't fire any catalog events), it relies on whatever event eventually arrives on the call to trigger one of its on edges. That makes it a clean fan-in point — you can wire ten different upstream branches into the same noop and have a single outgoing edge handle the union — and a clean labelling tool for complex graphs where a section needs a name ("after-hours branch", "VIP path", "post-recording cleanup"). It also works as a fallback for branch and setVar nodes where you want the unmatched-cases edge to land on something visible before continuing.

When to use it

• Label a section of a complex flow with a sticky-note title that shows on the canvas — "After-hours branch", "VIP express path", "Recording cleanup"
• Fan multiple incoming branches into a single outgoing path so the rest of the flow doesn't have to be duplicated under each branch
• Pin a longer explanation of a tricky decision in notes so the next person who opens the editor (or you in three months) sees why the wiring looks the way it does
• Use as the right-edge __next target on a branch while you're still designing the flow — gives you a visible "came out the default edge" marker that you can inspect in run telemetry
• Hold space on the canvas for a future node — drop a noop labelled "TODO: collect feedback" so the wiring is in place before the real node type is wired in

Configuration

A sticky note on the canvas. Use it to label a section ('after-hours branch'), explain a tricky decision to your future self, or as a junction where several arrows meet before continuing.

Examples

Fan-in junction

Three different upstream branches all converge on a single labelled node before a shared cleanup path. Edges target cleanup-junction.id and the junction has one outgoing edge.

{
  "id": "cleanup-junction",
  "type": "noop",
  "config": {
    "title": "Post-recording cleanup",
    "notes": "Every voicemail / record path lands here so we only run the goodbye prompt once."
  },
  "on": { "__next": "goodbye-prompt" }
}

Annotated default fallback for a branch

A branch node's right-edge fallback lands on a labelled noop so run telemetry shows "default path taken" by name. The noop's outgoing edge takes over from there.

{
  "id": "default-path-marker",
  "type": "noop",
  "config": {
    "title": "No tier matched",
    "notes": "Anyone whose vars.tier doesn't match gold/silver/trial ends up here."
  },
  "on": { "__next": "standard-queue" }
}

Gotchas

• noop does NOT auto-advance. Unlike setVar or httpCall, this node parks the flow and waits for an external event. That event is usually call.hangup or a bridge transition that arrived while we were sitting here — so wire those into on if you want anything to actually happen. A bare noop with no on map is a black hole.
• title and notes are editor-only. The worker never reads them. Putting {{vars.x}} in notes does not template — what you see on the canvas is what you get. If you want runtime logging or telemetry, use a customScript with log.info(...) instead.
• Wiring in/out of a noop costs an event hop. Every edge traversal counts as a node entry / exit in run telemetry, so a flow littered with decorative noop nodes will show twice as many node.enter / node.exit events as one without. Harmless for production but worth knowing if you're profiling a flow.
• noop is also the default switch fallback in the worker. Any unrecognized node type — typically a custom type added by a catalog edit that hasn't shipped to the worker yet — is handled by the noop case, so the flow doesn't crash. Useful as a safety net, but it can mask a typo in node.type because the flow appears to work (it just hangs on that node).