# Static vs Dynamic

In the last page you set TextProcessor's **operation** to `capitalize` in its configuration panel. To change it, you opened the editor, picked a different value, saved.

Configuration is a value you decide at design time. But TextProcessor also exposes `operation` as an **input port** — meaning another node can supply the value at run time. Same setting, two ways to source it.

This page shows the difference and why it matters.

## What you will learn

- How a single value can be sourced from configuration **or** a port
- How a connected port **overrides** the configured default
- When to lean on one vs. the other

## The setup

You should still have:

```
ChatInput ──▶ TextProcessor ──▶ ChatOutput
```

with TextProcessor configured to `capitalize`.

## Step 1: Add a TextInput node

1. Click **+** and add a **Text Input** (under **Text & Output**).
2. Click the new node and set its **defaultValue** to `uppercase`.

This node is small and dumb — it outputs whatever string you typed. We're going to use it as the "decision" about which operation TextProcessor should apply.

## Step 2: Wire it into TextProcessor's `operation` port

Drag from TextInput's `text` output to TextProcessor's **operation** input port.

```
┌─────────────┐
│  TextInput  │
│ "uppercase" │
└──────┬──────┘
       │ text
       │
       │       operation
       ▼
┌─────────────┐         ┌────────────────┐         ┌──────────────┐
│  ChatInput  │ message │ TextProcessor  │  text   │  ChatOutput  │
│             ├────────▶│  capitalize    ├────────▶│              │
└─────────────┘         └────────────────┘         └──────────────┘
```

Save the workflow.

## Step 3: Test

Open the Playground and type `hello world`.

You should get back `HELLO WORLD` — even though TextProcessor's _configured_ operation is still `capitalize`.

The connected port wins. The configured value only kicks in when no edge supplies one.

## Step 4: Change behavior without rewiring

Open TextInput in the editor. Change its **defaultValue** from `uppercase` to `lowercase`. Save.

Send `Hello WORLD` in the Playground. You get back `hello world`.

You changed the workflow's behavior without touching TextProcessor and without changing a single edge.

## What this proves

The same logical setting — _which operation should run_ — can live in two places:

- **As configuration** (a static default on TextProcessor): set once when designing the workflow, identical on every run.
- **As a port** (an input edge from another node): computed on every run, and free to vary based on whatever upstream logic you build.

This is the distinction [Flow › Chapter 7](../flow.md) ended on. Now you've felt it: ports are dynamic, config is static, and the same value can be either depending on how you wire the workflow.

## Which should you use?

| Use config when | Use a port when |
| --- | --- |
| The value is fixed for this workflow's purpose | The value depends on the input or upstream logic |
| You want a simpler graph | You want runtime flexibility |
| Different deployments don't need different values | The same workflow needs to behave differently per run |

A general rule: **start with config**. Promote a setting to a port the moment you find yourself wishing it could change per run.

## Next

[Re-building the Date Workflow →](date-workflow.md) — same pattern, but with a real-world processor that needs both config and ports.
