How to fix variable scoping issues with user context in n8n prompts?

The fix is to always store your user-specific context in a stable place (like the Workflow Data, a Set node, or a database) and then explicitly pull it into your prompt using n8n expressions such as {{$json.userName}}. In n8n, variables don’t have global scope inside prompts; they only exist in the JSON passed into the node. So the solution is to put your user context into the JSON of the previous node, then reference it directly inside the prompt with expressions. That removes scoping issues completely.

 

Why this fixes user‑context scoping in n8n

 

In n8n, every node receives only the JSON data output from the previous node(s). There is no concept of “global variables” or “session memory” inside a prompt. What feels like a scoping problem is actually that the node simply doesn’t see a variable you thought existed.

To fix this, the idea is: put everything the LLM node must use directly into the JSON right before it. Then reference it inside your prompt using the {{ }} expression syntax.

This ensures your prompt always has access to the correct user data no matter how the workflow is triggered or how many branches exist.

 

How to structure context correctly

 

• Create or modify a Set node that contains all user variables you need: userId, userName, previousMessages, settings, etc.
• Feed that Set node directly into the LLM node.
• Inside the LLM node prompt, use expressions like {{$json.userName}}.
• If you need persistent user context across runs, save/load it from a database node or an n8n Data Store.

 

Example: Fixing a broken prompt that “loses” variables

 

Imagine your LLM node prompt contains something like this:

Hello {{userName}}, here is your result...

This will fail because userName is not in scope. n8n cannot guess it. The prompt engine only sees the incoming JSON.

Correct approach: define the user context explicitly in a Set node.

{
  "userId": "123",
  "userName": "Alice",
  "plan": "pro"
}

Now the LLM node prompt can reliably access these values:

Hello {{$json.userName}}!

You are on the {{$json.plan}} plan.
Your ID is {{$json.userId}}.

This always works because the values exist in the node’s input JSON. No more scoping issues.

 

Handling longer‑term user context across workflow runs

 

If you need to carry user context across multiple runs (for example, a conversation or preferences), you must store it somewhere outside the node‑to‑node JSON flow. Good options are:

• Data Store node for quick state
• Postgres/MySQL for persistent user state
• Redis if you're running self‑hosted and need performance

Then at the start of the workflow you load the context, merge it with the new data using a Set node or Function node, and feed that clean JSON into your LLM node.

 

Summary: the production‑safe pattern

 

All user context must be explicitly placed into the JSON before the prompt, then referenced using {{$json.\*}} expressions. n8n never automatically exposes variables to prompts, so the fix is always to create stable structured JSON for the LLM node to consume. This keeps prompts deterministic, avoids scoping bugs, and works in production at scale.