Use Manual Trigger with Hardcoded Test Data

The Manual Trigger node fires when you click Test workflow, but on its own it outputs nothing. Follow it with a Set or Code node holding hardcoded test data to create a self-contained, repeatable test that needs no webhook, schedule, or external system. Both the test path and the production trigger can converge on the same processing nodes.

Why use a Manual Trigger with hardcoded test data?

The Manual Trigger node fires when you click "Test workflow" in the editor. On its own it produces empty output, but you can follow it with a Code node or Set node that provides hardcoded test data. This creates a self-contained, repeatable test that does not depend on external systems, webhooks, or scheduled events.

Real-world example: Your production workflow is triggered by a Stripe webhook, but during development you want to test without sending real payments. Create a Manual Trigger path with representative test data.

How do you provide hardcoded test data in n8n?

{
  "event_type": "invoice.payment_succeeded",
  "customer_email": "test@example.com",
  "customer_name": "Test User",
  "amount_paid": 9900,
  "currency": "usd",
  "invoice_id": "in_test_123456",
  "subscription_id": "sub_test_789",
  "items": [
    {
      "description": "Pro Plan - Monthly",
      "quantity": 1,
      "unit_amount": 9900
    }
  ]
}

How do you run test and production triggers in one workflow?

The workflow structure for testing:

Production path:
  Webhook Trigger -> [processing nodes...]

Test path (same workflow):
  Manual Trigger -> Set Node (test data) -> [same processing nodes...]

Both paths converge at the first processing node using a
Merge node or by connecting both to the same downstream node.

How do you test multiple scenarios?

Tip: Multiple Test Cases. Create multiple Set nodes with different test scenarios -- successful payment, failed payment, subscription cancellation -- and connect each to the Manual Trigger through a Switch node controlled by a workflow variable. This gives you a basic test suite within the workflow itself.

This pattern lets you develop and test the entire workflow without any external dependencies, which is especially valuable when the trigger only fires on real business events.

Related: Always Set an Error Workflow on Every Production Workflow · Break Large Workflows into Sub-Workflows