# N8n Impl Workflow Design

> >

- **Type:** Skill
- **Install:** `agentstack add skill-impertio-studio-n8n-claude-skill-package-n8n-impl-workflow-design`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [Impertio-Studio](https://agentstack.voostack.com/s/impertio-studio)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [Impertio-Studio](https://github.com/Impertio-Studio)
- **Source:** https://github.com/Impertio-Studio/n8n-Claude-Skill-Package/tree/main/skills/source/n8n-impl/n8n-impl-workflow-design

## Install

```sh
agentstack add skill-impertio-studio-n8n-claude-skill-package-n8n-impl-workflow-design
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# n8n Workflow Design Patterns

## Quick Reference

| Pattern | Primary Node | When to Use |
|---------|-------------|-------------|
| Sub-workflow | Execute Workflow | Reusable logic, separation of concerns, >20 nodes |
| Error handling | Error Trigger + Stop And Error | Centralized failure notification and recovery |
| Branching | IF / Switch | Conditional routing based on data values |
| Merging | Merge | Combining data from parallel branches |
| Looping | Loop Over Items | Batch processing, rate-limited API calls |
| Wait/Resume | Wait | Human approval, external callback, timed delay |
| Scheduling | Schedule Trigger | Recurring automated execution |

## Decision Tree: Which Pattern Do I Need?

```
Need to reuse logic across workflows?
├─ YES → Sub-workflow (Execute Workflow node)
└─ NO
   Need to handle failures gracefully?
   ├─ YES → Is it a single node that might fail?
   │  ├─ YES → continueOnFail + IF node to check $json.error
   │  └─ NO → Error workflow (Error Trigger node)
   └─ NO
      Need to route data conditionally?
      ├─ YES → Two outcomes? → IF node
      │        Multiple outcomes? → Switch node
      └─ NO
         Need to combine data from multiple sources?
         ├─ YES → Merge node (choose mode based on use case)
         └─ NO
            Need to process items in batches?
            ├─ YES → Loop Over Items node
            └─ NO
               Need to pause and wait?
               ├─ YES → Wait node (time, webhook, or form resume)
               └─ NO → Schedule Trigger for recurring execution
```

## 1. Sub-Workflow Patterns

### Execute Workflow Node

ALWAYS use the Execute Workflow node to call another workflow as a sub-workflow. NEVER duplicate logic across workflows.

**Parameter passing:**
- The calling workflow sends input items to the sub-workflow
- The sub-workflow receives items at its trigger node
- The sub-workflow returns its final output back to the caller

**Caller policy** (`callerPolicy` in workflow settings):
- `workflowsFromSameOwner` — Only workflows owned by the same user (DEFAULT)
- `workflowsFromAList` — Only workflow IDs listed in `callerIds`
- `any` — Any workflow can call this sub-workflow
- `none` — NEVER allow this workflow to be called as a sub-workflow

ALWAYS set `callerPolicy` explicitly on sub-workflows in production. NEVER leave it as default when multiple users share the n8n instance.

**When to extract a sub-workflow:**
- Logic is reused by 2+ workflows
- A workflow exceeds 20 nodes
- A distinct responsibility can be isolated (e.g., "send notification", "enrich contact")

See: [references/methods.md](references/methods.md) for Execute Workflow node details.
See: [references/examples.md](references/examples.md) for sub-workflow patterns.

## 2. Error Handling

### Three Layers of Error Protection

**Layer 1 — Node-level: continueOnFail**
- Enable `continueOnFail` on individual nodes that might fail
- Failed items pass through with `$json.error` containing the error message
- ALWAYS follow a continueOnFail node with an IF node to check `$json.error`

**Layer 2 — Node-level: Retry on Fail**
- Enable `retryOnFail` for transient failures (API timeouts, rate limits)
- Configure `maxTries` (default: 3) and `waitBetweenTries` (default: 1000ms)
- ALWAYS use retry for HTTP Request nodes calling external APIs

**Layer 3 — Workflow-level: Error Workflow**
- Create a dedicated error workflow starting with the **Error Trigger** node
- Assign it in the main workflow's Settings > Error Workflow
- One error workflow can serve multiple production workflows
- The Error Trigger receives execution context: workflow name, execution ID, error message

### Stop And Error Node

Use the **Stop And Error** node to deliberately fail a workflow when:
- Data validation fails
- Business rules are violated
- A required external resource is unavailable

This triggers the configured error workflow, enabling centralized error notification.

### Execution Timeout

Set `executionTimeout` in workflow settings to prevent runaway executions. Configure the global default via `EXECUTIONS_TIMEOUT` environment variable (default: disabled). Maximum allowed timeout is controlled by `EXECUTIONS_TIMEOUT_MAX` (default: 3600 seconds).

See: [references/methods.md](references/methods.md) for error handling node details.
See: [references/examples.md](references/examples.md) for error handling patterns.

## 3. Branching Patterns

### IF Node

The IF node evaluates conditions and routes items to one of two outputs:
- **Output 0 (true)**: Items matching the condition
- **Output 1 (false)**: Items NOT matching the condition

ALWAYS use the IF node for binary (true/false) decisions. NEVER use a Switch node with only two routes.

Conditions support:
- String: equals, contains, startsWith, endsWith, regex, isEmpty
- Number: equals, gt, gte, lt, lte, between
- Boolean: equals
- Date/time comparisons
- Combine with `and` / `or` combinators

### Switch Node

The Switch node routes items to multiple outputs based on rules or expression values:
- **Rules mode**: Define conditions per output (like chained IF nodes)
- **Expression mode**: Route based on the value of an expression

ALWAYS use the Switch node when routing to 3+ destinations. NEVER chain multiple IF nodes for multi-way branching.

### OnError Output

Every node supports the `onError` setting:
- `stopWorkflow` — Stop execution (default)
- `continueRegularOutput` — Send error data to the regular output
- `continueErrorOutput` — Send error data to a dedicated error output

See: [references/methods.md](references/methods.md) for IF and Switch node details.

## 4. Merge Patterns

The Merge node combines data from two or more inputs. ALWAYS choose the correct mode:

| Mode | Use Case | Behavior |
|------|----------|----------|
| **Append** | Combine all items from both inputs into one list | Concatenates items |
| **Combine > Merge By Fields** | Join items by matching field values | SQL-style JOIN |
| **Combine > Merge By Position** | Pair items by index position | items[0]+items[0], items[1]+items[1] |
| **Combine > Multiplex** | Create all combinations | Cartesian product |
| **Choose Branch** | Wait for one branch, discard others | First-to-complete wins |
| **SQL Query** | Complex data combination | Write SQL against inputs |

ALWAYS use "Merge By Fields" when combining data from different sources that share a key field. NEVER use "Merge By Position" for data with different item counts.

See: [references/methods.md](references/methods.md) for Merge node modes.

## 5. Loop Patterns

### Loop Over Items Node

The Loop Over Items node (formerly "Split In Batches") processes items in configurable batch sizes:

1. Splits the input items into batches of N
2. Sends each batch through the loop body
3. Collects results after all batches complete

**When to use:**
- API has rate limits (process N items, then pause)
- Memory-intensive operations (process in smaller chunks)
- Need to call an external API per item or per batch

ALWAYS set a reasonable batch size. NEVER process all items at once when calling rate-limited APIs.

**Loop body rules:**
- Connect the "Loop" output back to the first node in your processing chain
- Connect your processing chain's last node back to the Loop Over Items node
- The "Done" output fires after ALL batches complete

See: [references/examples.md](references/examples.md) for loop patterns.

## 6. Wait and Resume Patterns

### Wait Node

The Wait node pauses execution and resumes via:

**Resume on timer:**
- Wait a fixed duration (seconds, minutes, hours, days)
- Wait until a specific date/time

**Resume on webhook:**
- Generates a unique `$execution.resumeUrl`
- Execution pauses until an HTTP request hits that URL
- The incoming request data is available as the Wait node's output

**Resume on form:**
- Generates a form URL via `$execution.resumeFormUrl`
- Displays a form to the user
- Execution resumes when the form is submitted

ALWAYS use Wait node webhook resume for human-in-the-loop approvals. NEVER poll for status changes when a webhook callback is possible.

### Webhook Resume URL

Access the resume URL in expressions:
- `{{ $execution.resumeUrl }}` — Webhook resume URL
- `{{ $execution.resumeFormUrl }}` — Form resume URL

ALWAYS send the resume URL to the external system (e.g., in an approval email) BEFORE the Wait node pauses execution.

## 7. Scheduling Patterns

### Schedule Trigger

The Schedule Trigger node starts workflow execution on a schedule:
- **Interval**: Every N seconds/minutes/hours
- **Cron expression**: Standard cron syntax for complex schedules
- **Specific times**: At fixed times on specific days

ALWAYS set the correct timezone in workflow settings (`settings.timezone`). NEVER rely on the server's default timezone for scheduled workflows.

ALWAYS set `GENERIC_TIMEZONE` environment variable on deployment to ensure consistent schedule behavior.

### Cron Expression Quick Reference

| Expression | Meaning |
|-----------|---------|
| `0 * * * *` | Every hour at minute 0 |
| `0 9 * * 1-5` | Weekdays at 09:00 |
| `*/15 * * * *` | Every 15 minutes |
| `0 0 1 * *` | First day of every month at midnight |
| `0 8,12,17 * * *` | At 08:00, 12:00, and 17:00 daily |

## 8. Workflow Settings Reference

| Setting | Purpose | Default |
|---------|---------|---------|
| `errorWorkflow` | Workflow to execute on failure | None |
| `executionTimeout` | Max execution time (seconds) | Disabled (-1) |
| `callerPolicy` | Who can call this as sub-workflow | `workflowsFromSameOwner` |
| `callerIds` | Allowed caller workflow IDs (when policy = fromAList) | Empty |
| `timezone` | Timezone for schedule nodes | Instance default |
| `saveDataErrorExecution` | Save data on error | `all` |
| `saveDataSuccessExecution` | Save data on success | `all` |
| `executionOrder` | Node execution algorithm | `v1` |

## Design Principles

1. **ALWAYS** name nodes descriptively — "Fetch Customer Orders" not "HTTP Request1"
2. **ALWAYS** add notes to complex logic nodes explaining the business rule
3. **ALWAYS** set an error workflow on every production workflow
4. **ALWAYS** use sub-workflows for reusable logic — NEVER copy-paste nodes
5. **NEVER** build workflows with more than 30 nodes — extract sub-workflows
6. **NEVER** leave retry settings at default for external API calls — configure explicitly
7. **ALWAYS** test with pinned data before activating a workflow
8. **ALWAYS** set execution timeout on long-running workflows

## Reference Files

- [references/methods.md](references/methods.md) — Core workflow nodes: Execute Workflow, Merge, IF, Switch, Loop Over Items, Wait, Error Trigger, Stop And Error
- [references/examples.md](references/examples.md) — Sub-workflow, error handling, branching, loops, scheduling patterns
- [references/anti-patterns.md](references/anti-patterns.md) — Workflow design mistakes and how to avoid them

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [Impertio-Studio](https://github.com/Impertio-Studio)
- **Source:** [Impertio-Studio/n8n-Claude-Skill-Package](https://github.com/Impertio-Studio/n8n-Claude-Skill-Package)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-impertio-studio-n8n-claude-skill-package-n8n-impl-workflow-design
- Seller: https://agentstack.voostack.com/s/impertio-studio
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.