# Steps and Connections

> What a step is made of, how links between steps decide execution order, and how parallel branches merge back together.

A workflow is steps joined by links. This page covers what a step is made of and what a link decides: the model underneath the canvas, rather than the panels you click.

In Glow, **connection** can mean two different things. A **canvas connection** is the line that carries a run from one step to another. An **app connection** is the account a step uses to act in Slack, HubSpot or another service. This page is about canvas connections; [Connecting an App](/manage/apps-and-integrations/connecting-an-app) covers accounts.

For the panels themselves, see [The Dock & App drawer](/build/the-canvas/the-dock).

## Steps

Every step on the canvas carries a **number**, assigned as you add it. That number is its identity: it is how other steps refer to its output. Renaming the step does not change it. See [Variable Reference Syntax](/reference/variable-syntax).

A step has:

- **A type:** what it does, set by which dock entry created it. A Webhook, a Slack action, an AI Prompt.
- **Inputs:** terminals on its left edge, where incoming links arrive.
- **Outputs:** terminals on its right edge, where outgoing links leave.

A step can have several of each, which is what lets a workflow branch and merge.

## Links

A link joins one step's output to another's input. It settles two things at once: **what runs after what**, and **which data is available where**. A step can reference the output of anything upstream of it.

### Drag to connect
Drag from an output terminal towards the step you want to reach.

### Snap to input

Get close and the link snaps to the nearest input terminal. Release to confirm.

### Quick add

Or click the **+** on an output terminal. The dock opens inline, and the step you pick is placed and connected in one action.

### Working with an existing link

**Hover over a link** and its controls appear on the line:

| Control                 | What it does                                                                                                                       |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Data**                | Opens what actually travelled along this link on the last run (see below).                                                         |
| **Edit label**          | Name the link. The label sits on the line, so a branch can say _"high value"_ or _"needs review"_ on the canvas itself.            |
| **Add step in between** | Insert a step into the link. Glow splits the connection and rewires both halves for you, rather than making you delete and redraw. |
| **Remove connection**   | Delete the link, leaving both steps in place.                                                                                      |

Labelling links is worth the few seconds on anything with branches. Where every line is unnamed, the next person has to open each condition to work out which path is which.

#### Seeing what flows along a link

Click **Data** on a link and Glow shows the data that reached the step at its far end. It answers the question a canvas otherwise cannot: _what is actually passing between these two steps_. You never have to open either of them.

From there, **Open Data Flow** widens the view to the whole workflow. Follow a value from where it entered to where it is used. That is the fastest way to find out why a field arrives empty three steps later: you see which link it stopped travelling along.

Both read from the last run, so run the workflow at least once before expecting anything there.

## Merging parallel branches

A workflow that splits into parallel paths has to decide what happens where they come back together. In Glow that decision belongs to the step they meet at, and no separate merge or join step is needed.

A step with more than one incoming link carries a small **AND** / **OR** chip on the canvas. Click it and pick one of two options.

  
    **AND (Data from all steps):** the step waits for *every* incoming branch to finish and deliver its data before it runs.

    Use it when you need everything present at once. Two API calls fetch customer and billing data, and both must succeed before they merge into one record.

  
  
    **OR (Data from any step):** the step runs as soon as *any one* incoming branch delivers.

    Use it when the branches are alternatives. A lead is routed down the Europe, US, or Asia path, and a single logging step at the end runs whichever path was taken.

  

```mermaid
flowchart LR
    A[Fetch Customer] --> C[Write Record<br/>(AND: Waits for both)]
    B[Fetch Billing] --> C
    D[Europe Route] --> F[Log to Sheets<br/>(OR: Runs on either)]
    E[US Route] --> F
```

The two modes suit different shapes, and picking by shape is what keeps a merge predictable:

- **AND** is for branches that both always run — two steps you fanned out to work side by side, then brought back together. It waits for every incoming branch to deliver.
- **OR** is for branches that are alternatives, where only one is ever taken. That includes the two sides of a [Condition](/build/action-steps/conditions): merge those with OR.

[Combine](/build/action-steps/combine) always waits for both of its inputs, so give it two branches that both run.

### OR runs the step once per branch that arrives

This is the part worth knowing before you pick it. **OR does not run the step once and discard the rest.** It runs once for every incoming branch that delivers.

Where the branches are genuine alternatives, only one of them arrives, so the step runs once. That is the case OR is for.

Where both branches run and both arrive, the step runs twice. If it sends an email, two emails go out.

| Both branches can deliver              | Choose  |
| -------------------------------------- | ------- |
| Yes, and you want one result from both | **AND** |
| No, they are alternative routes        | **OR**  |
| Yes, and running twice is fine         | **OR**  |

If you want one run from branches that both deliver, that is **AND**, or a [Combine](/build/action-steps/combine) step when what you are merging is two lists.

## Error paths

A step can send failures somewhere other than its normal output. Set its **If this step fails** to _Continue_ and a **Select Error Path** button appears beneath the setting. Pick the step a failure should route to, either an existing one or a new one you add there, and Glow draws the error path on the canvas as its own line beside the normal output.

See [Error Handling](/build/core-concepts/error-handling).

## What's Next?

- 👉 **[Triggers and Actions →](/build/core-concepts/triggers-and-actions)**: learn what starts a run and what the later steps do.
- Learn where steps come from and how to configure them in [The Dock & App drawer](/build/the-canvas/the-dock).