# Understanding Execution Modes in n8n: Manual, Trigger, Scheduled, and Beyond

> Explore n8n execution modes like manual, trigger, and scheduled. Learn how to control workflow starts and engine processing for efficient automation. Discover all ten modes.

- Repository: [n8n - Workflow Automation/n8n](https://github.com/n8n-io/n8n)
- Tags: deep-dive
- Published: 2026-02-24

---

**n8n supports ten distinct execution modes—including manual, trigger, webhook, cli, integrated, internal, retry, evaluation, chat, and error—that control how workflows start and how the engine processes them.**

In the n8n-io/n8n repository, execution modes define the runtime context for every workflow run. These modes, defined in [`packages/workflow/src/execution-context.ts`](https://github.com/n8n-io/n8n/blob/main/packages/workflow/src/execution-context.ts), determine whether a workflow runs as a user-initiated test, a scheduled production job, or an internal retry attempt, directly impacting logging, persistence, and retry behavior.

## What Are Execution Modes in n8n?

Execution modes in n8n describe **how a workflow was initiated** and instruct the engine on how to handle the run. The canonical list is encoded in the `WorkflowExecuteModeSchema` Zod union type, which validates the mode string throughout the application.

According to the source code in [`packages/workflow/src/execution-context.ts`](https://github.com/n8n-io/n8n/blob/main/packages/workflow/src/execution-context.ts) (lines 33-44), the valid execution modes are:

```typescript
const WorkflowExecuteModeSchema = z.union([
    z.literal('cli'),
    z.literal('error'),
    z.literal('integrated'),
    z.literal('internal'),
    z.literal('manual'),
    z.literal('retry'),
    z.literal('trigger'),
    z.literal('webhook'),
    z.literal('evaluation'),
    z.literal('chat'),
]);

```

Each literal corresponds to a specific entry point into the n8n execution engine.

## The Complete List of n8n Execution Modes

The ten execution modes serve distinct operational purposes:

- **`manual`** – Triggered when a user clicks **Run** in the UI or starts a workflow via the CLI `run` command. The engine treats this as a test run with real-time UI output and no retry handling.
- **`trigger`** – Activated when any trigger node fires, including the **Schedule Trigger**, **Webhook Trigger**, **Cron**, or polling mechanisms. This mode indicates a regular production execution that may be queued and retried.
- **`webhook`** – Specifically for webhook requests hitting an n8n endpoint. Similar to `trigger` but provides the raw payload in `event.body`.
- **`cli`** – Used when executing workflows via the `n8n exec` command for headless automation or CI/CD pipelines.
- **`integrated`** – Occurs when the **Execute Workflow** node calls another workflow. This mode shares the parent execution context, allowing direct data return without serializing through the database.
- **`internal`** – Reserved for internal mechanisms like error-workflow handling or retry processing. Runs with reduced logging and no external side effects.
- **`retry`** – Applied when a node or workflow re-executes after a failure. Preserves the original execution ID for accurate error tracking.
- **`evaluation`** – A sandbox mode used by the UI when previewing expressions or testing node configurations. Never persists data.
- **`chat`** – Dedicated to the n8n AI-Chat feature, enabling streaming output and special handling for chat-type nodes.
- **`error`** – Specifically for error-workflow execution when a parent workflow fails, isolating error handling logic.

## How Execution Modes Affect Runtime Behavior

The execution mode determines branching logic throughout the n8n engine. In [`packages/cli/src/workflow-runner.ts`](https://github.com/n8n-io/n8n/blob/main/packages/cli/src/workflow-runner.ts) (lines 241-247), the runner checks the mode to decide whether to apply special handling for UI-only runs:

```typescript
if (['manual', 'evaluation'].includes(data.executionMode)) {
    // special handling for UI preview / manual runs
}

```

Node developers can access the current mode at runtime using `this.getMode()`, available on all node function implementations. This allows conditional logic based on how the workflow started.

## Practical Code Examples

### Detecting Manual Execution Inside a Node

Use `this.getMode()` to execute logic only during user-initiated test runs:

```typescript
if (this.getMode() === 'manual') {
    // Do something that should only happen when a user clicks “Run”
    console.log('Running in test mode - skipping external API calls');
}

```

### Running a Scheduled Trigger Workflow

The **Schedule Trigger** node (located in [`packages/nodes-base/nodes/Schedule/ScheduleTrigger.node.ts`](https://github.com/n8n-io/n8n/blob/main/packages/nodes-base/nodes/Schedule/ScheduleTrigger.node.ts)) automatically initiates workflows with the `trigger` mode. To emulate this in tests:

```typescript
const executionMode = 'trigger';   // emulate a schedule/webhook start
const workflowExecute = new WorkflowExecute(additionalData, executionMode);
await workflowExecute.run();

```

### Executing Workflows via CLI

The `cli` mode is automatically set when using the command line:

```bash
n8n exec --workflow-id=456

```

This bypasses the UI and runs the workflow headless, returning results to stdout.

### Calling Integrated Workflows

When using the **Execute Workflow** node, n8n automatically sets the mode to `integrated`:

```typescript
await this.executeWorkflow({
    workflowId: 'sub-workflow-id-123',
    // mode is automatically set to 'integrated' by the engine
});

```

This mode maintains the execution context chain, allowing the parent workflow to receive return data directly from the child execution.

## Summary

- n8n defines ten execution modes in [`packages/workflow/src/execution-context.ts`](https://github.com/n8n-io/n8n/blob/main/packages/workflow/src/execution-context.ts): `manual`, `trigger`, `webhook`, `cli`, `integrated`, `internal`, `retry`, `evaluation`, `chat`, and `error`.
- **Manual** and **evaluation** modes receive special handling in [`packages/cli/src/workflow-runner.ts`](https://github.com/n8n-io/n8n/blob/main/packages/cli/src/workflow-runner.ts) for UI preview scenarios.
- **Trigger** mode represents standard production runs initiated by schedule, webhook, or polling nodes.
- **Integrated** mode enables seamless parent-child workflow communication without database persistence overhead.
- Node code can detect the current mode via `this.getMode()` to adjust behavior for testing versus production contexts.

## Frequently Asked Questions

### What is the difference between manual and trigger execution modes in n8n?

The **manual** execution mode is used when a user clicks the Run button in the UI or uses the CLI `run` command, creating a test environment where the UI displays real-time output but disables retry mechanisms. The **trigger** mode indicates a production execution started by a trigger node (Schedule, Webhook, Cron), which enables full queueing, retry logic, and persistent storage of execution data.

### How can I check which execution mode my n8n node is running in?

Access the current execution mode by calling `this.getMode()` within any node function implementation. This method returns a string literal such as `'manual'`, `'trigger'`, or `'integrated'`, allowing you to write conditional logic that behaves differently during testing versus production runs.

### What happens when a workflow calls another workflow in n8n?

When the **Execute Workflow** node invokes a child workflow, n8n automatically sets the execution mode to `integrated`. This mode shares the parent's execution context, enabling the child to return data directly to the parent without creating a separate database entry, significantly improving performance for nested automation logic.

### Can I force a specific execution mode when running n8n from the command line?

Yes. When using the `n8n exec` command to run workflows headless, the system automatically assigns the `cli` execution mode. You cannot override this to `manual` via CLI arguments, as the `cli` mode specifically indicates headless operation without UI attachment, distinguishing it from user-interactive runs.