I deleted a user and moved all the workflows/credentials to another user. Now some those workflows are unable to call some sub-workflows or access data tables (even if newly created). The data table / workflow IDs are correct. The error happens when I pull them from list or define the id.
If I create a new workflow, then I am able to call the sub-workflows / access data tables. To note, both the primary and sub-workflows were transferred from the deleted user.
I don’t see any reason why some of these are working and some not. Any causing problems can be solved by creating a new workflow and copy pasting the nodes.
@flowdan both errors are the same root cause, the transfer scattered things across different projects and both data tables and sub-workflow calls are owner/project scoped. a data table is only visible inside the project it lives in, so “could not find the data table” means that table ended up in a different project than the workflow trying to read it, not that the id is wrong. the sub-workflow one is the caller policy, n8ns default is workflowsFromSameOwner (the N8N_WORKFLOW_CALLER_POLICY_DEFAULT_OPTION setting), and owner here maps to the project, so if the parent and the sub landed in different projects after the move you get “cannot be called by this workflow”. thats also exactly why a brand new workflow works, it gets created in whatever project youre currently in, right alongside those resources. fix is to get the parent, its sub-workflows and the data tables back into the same project instead of split across a couple, and for a quick unblock on the sub-workflow side you can open each sub-workflow, Settings, and set “which workflows can call this” to Any workflow. did the transfer drop everything into one project or split it across personal/team projects?
@flowdan ah ok, no projects changes the framing, then “owner” in that caller-policy is just the user. what it points to is the delete and transfer not cleanly re-owning those specific workflows, theyre running under a stale/mismatched owner from the deleted account, and since both the data table lookup and the sub-workflows same-owner caller check run in the workflows owner context, they fail there but work fine from a freshly created one. thats exactly why copy-pasting the nodes into a new workflow fixes it, that new workflow is cleanly owned by you. for the sub-workflow half you can skip the re-own and just open the sub, Settings, set “which workflows can call this” to Any workflow (or set N8N_WORKFLOW_CALLER_POLICY_DEFAULT_OPTION=any instance-wide), that drops the same-owner check entirely. the data table side doesnt have that toggle so those you fix by re-owning, ie the copy-paste youre already doing. fwiw the clean re-assignment not happening on user delete looks like a bug worth reporting with your version attached.
n8n sometimes caches ownership and permission sets in memory. If you transferred the workflows while the instance was running, the server might still be using the old permission map for those specific workflow IDs.
If you haven’t already, restart your n8n instance. This clears the internal cache and forces n8n to re-evaluate the ownership and project permissions for all workflows from the database. In many cases, this resolves sub-workflow call errors.
@flowdan thats the missing piece, that per-workflow “can be called by” toggle only shows when workflow sharing is enabled, so on community self-hosted its not in that settings panel at all, which is exactly why you cant find it. on community the caller rule is set instance-wide instead, through an env var. add N8N_WORKFLOW_CALLER_POLICY_DEFAULT_OPTION=any to your n8n containers environment and restart, that flips the default off workflowsFromSameOwner (the thing blocking you, since the transferred owner no longer matches) so any workflow can call any sub-workflow. thats also why the plain restart alone didnt fix it, a restart only clears the in-memory cache, the policy default itself doesnt change until you set that variable. one heads up, the env var only covers the sub-workflow calls, the “could not find data table” ones are the stale-ownership side so those still need the copy-paste re-own (or yeah, reverting + a bug report is fair if you want a clean slate). but id try the variable first, itll clear every sub-workflow error in one shot without reverting.
If you are self-hosting and have access to the database (PostgreSQL/SQLite), you can check the shared_workflow and project_relations tables.
Ensure that the projectId associated with the problematic workflows matches the projectId of your new user’s personal project.
If there are entries pointing to a userId or projectId that no longer exists, updating those IDs to the new user’s IDs can fix the issue globally without manual copy-pasting.
@flowdan good stuff, that variable was the missing lever. the only other resource that carries owner context the same way is credentials, and you moved those across too, so id spot-check that the transferred workflows can still use theirs, if a node throws a credential error its the same stale-owner thing rather than a fresh problem. regular nodes dont hold any ownership though, so past data tables and credentials you shouldnt have lurking surprises hiding in there.
I had issues in a few other workflows, so I got into the db and checked for old/missing user/project IDs… everything was correct. I checked any table that seemed relevant, nothing stuck out.
One in particular that I fixed by recreating- The issue was that it would let me create a data table in the workflow, but it would still not allow me to read/write. I could go to the data tables tab and view/edit. Looking at the db tables, the workflow and data table already had the right projectId.
So yea, no clue where these issues actually existed in the db. Cache not clearing properly? I restarted the container multiple times, as well as the entire stack.
If anyone from n8n wants logs or anything please let me know. I’m not sure how to submit this as a bug report.
The fact that you checked the relational columns (like projectId and userId) and found them correct, yet the issue persisted. It confirms that the problem isn’t in the relational mapping, but in the serialized data.
This is definitely a bug in the “User Deletion/Transfer” logic—the transfer process is updating the relational IDs but failing to scrub the serialized JSON settings and internal security contexts.
To help reproduce this, provide the following to Github to open a bug report:
n8n Version: (e.g., 1.x.x)
Deployment Type: (Docker, npm, Cloud)
The “Broken” JSON vs “Fixed” JSON: Export a workflow that was failing and one that you fixed by recreating. If you compare the two JSON files, you might actually see a difference in the settings block (like a callerPolicy or permissions field) that proves where the ghost data is.
The specific error message: Include the screenshot you shared here.
If you have too many workflows to copy-paste, the fastest “bulk” fix is to use the n8n CLI to export all workflows to JSON and then re-import them. This forces every single workflow to be rewritten into the database with a fresh, clean context tied to the current user.
The callerPolicy is different, “callerPolicy”: “workflowsFromSameOwner” on the old ones, “callerPolicy”: “any” on the new ones. The old one has this templateCredsSetupCompleted parameter in meta, the new one doesn’t.
