# Branching with Gateways

So far the workflow has been one path with optional side-effects. Real workflows usually need to **decide**: do this if the input looks like X, otherwise do that.

This page introduces the nodes that handle decisions: **gateways**.

## What you will learn

- How **IfElse** picks one of two branches based on a condition
- How **SwitchGateway** picks one of many branches by matching a value
- How branch outputs are trigger edges, not data edges

## Gateways at a glance

Gateway nodes are diamond-shaped in the editor. They evaluate something and activate one of their **branch outputs**. The activation is a trigger — only the downstream nodes connected to the active branch will execute on that run.

The full reference is in [Control Flow Nodes](../../guide/nodes/control-flow.md). Here we'll use two:

- **IfElse** — two branches: True / False.
- **SwitchGateway** — many branches, named by you.

## Setting up

You can either keep adding to the Tutorial workflow or start fresh. To keep this page focused, we'll redo the canvas:

1. Open the **Tutorial** workflow.
2. Delete everything except **ChatInput** and **ChatOutput** (you can also leave the second ChatOutput in place — we'll use it).

We'll build a tiny chatbot that responds differently depending on what the user typed.

## Part 1: IfElse — two branches

Let's say: if the user types `hello`, greet them; otherwise, say we didn't catch that.

### Step 1: Add an IfElse node

Click **+**, find **IfElse** (under **Control Flow**), drop it on the canvas.

Click it to configure:

- **operator**: `equals`
- **matchText**: `hello`
- **caseSensitive**: off

### Step 2: Add two response nodes

Add two **Text Input** nodes. Set their **defaultValue** to:

- `Hi there!`
- `Sorry, I didn't catch that.`

Add a second **ChatOutput** so each branch has its own output target. (You can route both branches to the same ChatOutput, but two makes the diagram clearer.)

### Step 3: Wire it up

Data flow:

1. ChatInput's `message` → IfElse's `data` input
2. TextInput "Hi there!" `text` → first ChatOutput's `message`
3. TextInput "Sorry…" `text` → second ChatOutput's `message`

Trigger flow (the new bit):

4. IfElse's **True** branch output → first ChatOutput's **trigger** input
5. IfElse's **False** branch output → second ChatOutput's **trigger** input

```
                                                  ┌──▶ TextInput  ──data──▶ ChatOutput #1
                                                  │       "Hi there!"           ▲
                                                  │                             │ trigger
ChatInput ──data──▶ IfElse ── True branch ────────┘                             │
                       │                          ┌────────────────────────────┘
                       └── False branch ──────────┴──▶ TextInput ──data──▶ ChatOutput #2
                                                       "Sorry, I didn't
                                                        catch that."
```

### Step 4: Test

Save. In the Playground, type:

| Input | Output |
| --- | --- |
| `hello` | `Hi there!` |
| `hi` | `Sorry, I didn't catch that.` |
| `goodbye` | `Sorry, I didn't catch that.` |

The True branch fires only when the input equals `hello`; everything else lands on False.

### What's happening

- ChatInput hands the message to IfElse via a **data edge**.
- IfElse compares the value against `matchText`.
- It activates exactly one of its branch outputs — either True or False.
- Each branch is a **trigger edge**: it fires the connected ChatOutput, but doesn't carry data.
- The ChatOutput's `message` value comes separately, from the upstream TextInput's data edge.

This is exactly the trigger-vs-data distinction from the previous page. Gateways are where you'll meet trigger edges most often.

## Part 2: SwitchGateway — many branches

Two branches gets you yes/no. **SwitchGateway** scales that to as many cases as you need.

### Step 1: Replace IfElse with a SwitchGateway

Delete the IfElse node. Add a **Switch Gateway** (Control Flow). Click it to configure:

- **branches**: define three branches with these match values:
    - `hello`
    - `bye`
    - `time`
- **default_branch**: name it `unknown`

Each match value gives you a named branch output port. The default branch fires when nothing matched.

### Step 2: Wire branches to responses

You'll need four ChatOutputs (or one ChatOutput per branch — your call).

Wiring shape:

```
                  ┌── hello   ──trigger──▶ TextInput "Hi!"     ─▶ ChatOutput
                  │
ChatInput ──data──▶ Switch ── bye    ──trigger──▶ TextInput "See you!"     ─▶ ChatOutput
                  │
                  ├── time   ──trigger──▶ DateTime ──▶ PromptTemplate "It's {{now}}" ─▶ ChatOutput
                  │
                  └── unknown ──trigger──▶ TextInput "I don't follow."  ─▶ ChatOutput
```

(That last branch reuses what you built on the [Date Workflow](date-workflow.md) page — DateTime + PromptTemplate.)

### Step 3: Test

| Input | Branch | Output |
| --- | --- | --- |
| `hello` | `hello` | `Hi!` |
| `bye` | `bye` | `See you!` |
| `time` | `time` | `It's 2026-04-28 14:32` |
| anything else | `unknown` | `I don't follow.` |

## Why two gateway nodes

IfElse and SwitchGateway are the same idea at different scales:

| Use IfElse when | Use SwitchGateway when |
| --- | --- |
| You have exactly two outcomes | You have three or more |
| The decision is yes/no by nature | The decision is "which one of N" |
| You want explicit True/False semantics | You want named, descriptive branches |

There are other gateway nodes too — see [Control Flow Nodes](../../guide/nodes/control-flow.md) for **Boolean Gateway** (route on an existing boolean value) and **A/B** (random routing for testing).

## Where you've ended up

You've built a workflow that:

- Reads input from the user (ChatInput, Page 1)
- Transforms data with a processor (Page 2)
- Resolves config vs. dynamic values (Page 3)
- Combines two upstream nodes into one downstream node (Page 4)
- Sequences side-effects with trigger edges (Page 5)
- Routes execution into different paths based on input (this page)

That's most of FlowDrop's core. Everything beyond — entity operations, HTTP requests, AI integration, loops, human-in-the-loop interrupts — is more nodes plugged into the same shape.

## Next steps

- **[FlowDrop Vocabulary](../concepts.md)** — formal recap of all the terminology, plus the bits we glossed over.
- **[Node Reference](../../guide/nodes/index.md)** — every built-in node, with full ports and configuration.
- **[Setting Up Triggers](../../guide/triggers.md)** — run workflows from real Drupal events instead of the Playground.
- **[Production Deployment](../../guide/production-deployment.md)** — when you're ready to ship.
