Two Rules About n8n's Execute Workflow Node That I Learned From Its Error Messages

Rule one: publish the child before the parent

On the scratch test, publishing a parent whose Execute Workflow node pointed at an inactive child was rejected with an HTTP 400:

Cannot publish workflow: Node "Call Child" references workflow <id> ("<name>")
which is not published. Please publish all referenced sub-workflows first.

The message is clear, but it arrives at the end of the build: I had wired the parent first and only found out when saving it. The order that works is child first, publish it, then add or publish the parent. A sub-workflow whose only trigger is an Execute Workflow Trigger still has to be published, even though nothing will ever fire it on its own.

Rule two: the child needs an Execute Workflow Trigger

With the child published and the parent active, I pointed a second parent at a workflow whose only trigger was a Schedule Trigger. The parent's run failed:

SubworkflowOperationError: Missing node to start execution
Please make sure the workflow you're calling contains an Execute Workflow Trigger node

The webhook that started the parent returned only a bare 500 "Error in workflow"; the reason was in the execution's error details. A Schedule Trigger is a way for the clock to start a workflow, not a way for another workflow to start it.

Which also means a schedule-only workflow can't be test-fired this way

It's tempting to work around it with a throwaway parent that calls the workflow you want to test. That fails with the message above. What does work is temporarily adding a Webhook node wired straight to the first real node of the target workflow, calling it once, and removing the node afterwards. Be careful with that on anything that publishes: on a publisher workflow it is a real publish, not a dry run.

Where each rule bites

Rule one bites when you build top-down and save the caller first. Rule two bites when you split an existing scheduled workflow and leave its original trigger in place on the half you turned into a child. Because a workflow can hold more than one trigger node, a child that must also run on its own timer can carry both an Execute Workflow Trigger and its Schedule Trigger. I haven't needed that yet, so treat it as a suggestion rather than a tested pattern.