# Mastering Your n8n Workflows: How to Use Multiple Triggers for One Process As you build more complex automations in n8n, you'll often want a single workflow to run from different starting points. Maybe you want an AI Agent to respond to a live chat message, but also run on a schedule to process overnight tasks. This is a common and powerful pattern, but it can lead to frustrating errors if not set up correctly. This guide will walk you through the challenge and the simple, robust solution. ### The Challenge: Inconsistent Input Data The problem arises because **different trigger nodes produce different data structures**. - A **Schedule Trigger** outputs a simple, often empty, JSON object. - A **When chat message received** trigger outputs an object with details like `message`, `user`, and `channel`. - A **Webhook** trigger outputs data based on whatever the sending service provides, which could include `body`, `headers`, and `queryParameters`. Let's look at the example from your setup. Your **AI Agent** was configured to get its user prompt from a field named `prompt`. When your **Schedule Trigger** runs, you use an `Edit Fields` node to manually create this `prompt` field. This works perfectly. However, when the **When chat message received** trigger fires, it sends data like `{"message": "Hello AI"}`. The AI Agent looks for a `prompt` field, doesn't find one, and either fails or doesn't know what to process. Simply connecting both trigger paths to the same node creates a data collision. The downstream node has no guarantee of what the incoming data will look like. ### The Solution: Standardize and Merge The key to solving this is to ensure that no matter which trigger starts the workflow, the data arriving at your core processing node (e.g., the AI Agent) has the **exact same structure**. This is a two-step process. #### Step 1: Standardize Each Trigger's Output Before doing anything else, you must reshape the output of each trigger path so it becomes identical. The `Set` node is perfect for this. For your **Schedule Trigger** path: - You're already doing this with an `Edit Fields` node, which is great! You're creating a `prompt` field with a predefined value. For your **Chat Trigger** path: - Place a **Set** node immediately after the `When chat message received` trigger. - Configure it to create a new field named `prompt`. - Set its value using an expression to pull the text from the chat trigger's output, for example: `{{ $json.message }}`. - **Crucially, enable the "Keep Only Set" option.** This strips away all other data from the trigger, leaving you with a clean, single-field output: `{"prompt": "Hello AI"}`. Now, both paths produce a simple object with a single key named `prompt`. #### Step 2: Combine Paths with a Merge Node With your data standardized, you can now safely combine the two paths into one. 1. Place a **Merge** node on your canvas. 2. Connect the output of your `Edit Fields` node (from the schedule path) to **Input 1** of the Merge node. 3. Connect the output of your `Set` node (from the chat path) to **Input 2** of the Merge node. 4. Connect the single output of the Merge node to your **AI Agent**. Your final, corrected workflow will have a clear and logical flow like this: Now, regardless of whether the workflow is started by the schedule or a chat message, the AI Agent receives the exact data structure it expects. Your memory, tools, and models will function reliably every time. ### Are n8n Workspaces Isolated? To answer your other question: **Yes, n8n workspaces are completely isolated from each other.** - **Isolation by Design:** Workspaces are designed to be separate containers for your projects. This is useful for organizing workflows for different clients, separating development and production environments, or just keeping different automation projects from interfering with one another. - **No Shared Variables:** Variables, credentials, workflows, and execution data in one workspace are **not accessible**from another workspace. You cannot define a variable in Workspace A and read it from a workflow in Workspace B. This separation is a core feature for security and organization. If you need to share data between workflows across different workspaces, you would have to treat them as separate applications and use a method like a webhook or a shared external database to pass information between them.