How can I debug and inspect data passed to a sub-workflow AI agent in n8n?

Below is an explanation of how you can inspect the data passed from your primary workflow into the sub-workflow so you can better configure an intermediary “Edit Fields” node.

How Data Flows Between Workflows

When using the Execute Workflow node in your primary workflow, the data gets sent to the sub-workflow’s Execute Workflow Trigger node. The incoming object (or objects) can be viewed as the node’s input. You can use this behavior to debug and adjust the payload before handing it over to the AI agent node.

For example, in one of our AI workflows (like the “Ask a human” example), the Execute Workflow Trigger immediately passes the data to subsequent nodes. By inserting an Edit Fields (or Set) node right after the Execute Workflow Trigger node in your sub-workflow, you can inspect and adjust the fields. With this setup, you can:

• View the incoming data – open the node’s execution details and inspect the JSON it receives.
• Modify or map fields – use the Edit Fields/Set node to reformat or change keys so that the downstream AI agent receives them in the expected format.

Steps to Inspect the Data

1. Insert a Debugging Node:
   After the When Executed by Another Workflow node (the Execute Workflow Trigger), add an Edit Fields (or a Set) node. Configure it to pass through the data as is, or add extra fields to output the raw JSON.

2. Check Execution Data:
   Execute the workflow and, in the sub-workflow’s execution logs, click on the Edit Fields node. n8n’s node inspector will show you the data that is being passed from the parent workflow. This will let you see exactly what fields are available.

3. Adjust Accordingly:
   Once you understand the data structure, configure your Edit Fields node to re-map or remove fields so that when it reaches the AI agent node, the payload is as expected.

Relevant Documentation

• Subworkflow Data Flow:
  Refer to the section on how data passes between workflows (using the Execute Workflow and Execute Workflow Trigger nodes). This shows that the data from the parent workflow directly becomes the input of the sub-workflow.

• Execute Workflow Node:
  The documentation for the Execute Workflow node details how to pass data between workflows and provides guidance on the configuration options if you need to change the execution mode.

Example Workflow Summary

Although your primary workflow’s final output is “workflow completed” (which is just a placeholder message), this doesn’t reveal the sub-workflow’s input. By inserting the Edit Fields node in the sub-workflow directly after the Execute Workflow Trigger node, you’ll be able to see the complete data structure sent by the primary workflow.

This approach is similar to how our “Ask a human” workflow is arranged: the primary workflow directs requests to a sub-workflow, and by examining the node inputs (using the node execution details), you can determine which fields are available and thus adjust your configuration.

Final Output

The final output from your primary workflow remains “workflow completed”. However, the key to debugging is to focus on the sub-workflow—in particular, the data provided at the Execute Workflow Trigger node. Once you add a node to inspect that data, you should see exactly what is being passed in the node inspector, allowing you to adjust your Edit Fields node appropriately.

I hope this helps you set up your debugging steps effectively!