If you open the subworkflow node in the failed execution, you should see the full error message with the reason for the denial. Is that not showing for you?
The sub-workflow (J7gXMgGROfKy2PuF) cannot be called by this workflow"
No more than in logs given !
I have only one user, I’ve checked in DB for same user!
I think it’s something like a different thread stuff linked to LLM that introduce it (as opposed to direct call that is working)
Aside from the message The sub-workflow (ID) cannot be called by this workflow in the toast, if you open the Execute Workflow node in your parent workflow, you should see the reason below the error message. Does this not show for you?
1 - I can call the sub workflow if not calling it after LLM. That mean I have the permission !
2 - I have not the setting to restrict workflow permission (self hosted community edition).
3- The workflow is queued and marked as success in the main workflow !
Checking “wait for reply” in the caller workflow, I have this detailed error now. Please help me (I have no option in setting of the child workflow to change permissions):
The sub-workflow (J7gXMgGROfKy2PuF) cannot be called by this workflow
The sub-workflow you’re trying to execute limits which workflows it can be called by. You will need John to update the sub-workflow (J7gXMgGROfKy2PuF) settings to allow this workflow to call it.
Error details
n8n version 1.64.3 (Self Hosted)
Stack trace
SubworkflowPolicyDenialError: The sub-workflow (J7gXMgGROfKy2PuF) cannot be called by this workflow at SubworkflowPolicyChecker.check (/usr/local/lib/node_modules/n8n/dist/subworkflows/subworkflow-policy-checker.service.js:52:15) at processTicksAndRejections (node:internal/process/task_queues:95:5) at Object.executeWorkflow (/usr/local/lib/node_modules/n8n/dist/workflow-execute-additional-data.js:564:9) at Object.executeWorkflow (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:2320:24) at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/ExecuteWorkflow/ExecuteWorkflow.node.js:236:40) at Workflow.runNode (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/Workflow.js:722:19) at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:711:51 at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:1141:20
Note on using an expression here: if this node is set to run once with all items, they will all be sent to the same workflow. That workflow’s ID will be calculated by evaluating the expression for the first input item.
Any data you pass into this node will be output by the Execute Workflow Trigger. More info
I have a self-hosted - license: community.
According to documentation:
“* This workflow can be called by: choose whether other workflow can call this workflow. Requires Workflow sharing.”
So sharing setting is “Available on Pro and Enterprise Cloud plans, and Enterprise self-hosted plans.”
But I don’t need extra settings of sharing I only need the workflow to be executed by all!
So it’s definitively a bug or you not mentionning that the queue mode is not available in community version!
I think it’s not a bug. In my case, my redis had old projects cached. Those projects are compared when the sub-workflow execution policy is workflowsFromSameOwner, which is the default value.
To solve this issue, I just deleted the workflow-project key from redis. The full command is DEL n8n:cache:workflow-project.
Another way of solving this is setting an explicit policy through configuration. You can set N8N_WORKFLOW_CALLER_POLICY_DEFAULT_OPTION to any.
First, it loads the sub-workflow execution policy (here). The default value is workflowsFromSameOwner, see here. In my case, it loaded the default policy, so it checked if the workflows belong to the same ‘owner’. Owner, according to the code here, is the projectId.
The projectId is cached per workflow (see here). Since I created different projects (by deleting the db over and over again XD) and always imported the same workflows, the cache was invalid. It mapped the workflowId to the wrong projectId thus failing the workflowsFromSameOwner policy.