How to pass the information input by the user during interaction with the intelligent agent to the input parameters of the referenced workflow tool

[James-Bond123]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.7.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

How to configure the input nodes that pass user input information into the workflow when publishing the workflow as a tool and referencing it in the agent?

✔️ Expected Behavior

Please give me an answer

❌ Actual Behavior

No response

[dosubot[bot]]

Hi @James-Bond123! I'm Dosu and I’m helping the dify team.

To pass user input from an agent to the input parameters of a referenced workflow tool in Dify 1.7.2, follow these steps:

1. Define input variables in your workflow's Start Node (the "User Input" node). For each piece of user data you want to pass (e.g., query, name), add a corresponding input variable in the Start Node. Only variables defined here can be mapped from agent/user input ref.

2. Publish the workflow as a tool. When you do this, Dify automatically generates the tool's parameter schema based on the Start Node input variables. Make sure all required user inputs are present before publishing ref.

3. In your Agent node, add the published workflow tool. In the agent's tool configuration, you will see the input parameters defined in the workflow. Map each tool parameter to the agent variable or user input you want to pass. For example, map the agent's query variable to the workflow tool's query parameter ref.

4. When embedding or calling the agent, provide user input via the inputs field (e.g., in difyChatbotConfig.inputs or the API request's inputs object). Dify will automatically map these to the workflow tool parameters if the names match ref.

5. In the workflow, reference the input as {{variable}} (e.g., {{query}}). This will resolve to the value passed from the agent/user input ref.

Known limitations in 1.7.2:

• There is a bug where variables may not resolve correctly when a workflow is used as a tool in an agent, especially for numeric parameters or when variables contain special characters. If you see empty values or errors, this is likely the cause. Workarounds include calling the workflow directly (not as a tool in an agent) or upgrading to a newer version if possible ref, ref, ref.

Best practices:

• Always define all expected user input variables in the Start Node before publishing the workflow as a tool.
• Use the inputs field for passing user data; do not rely on userVariables or systemVariables for general workflow variable resolution ref.
• For advanced mapping, you can customize the workflow by extending the ToolNode class and its _generate_parameters method, but this is rarely needed for standard use cases ref.

If you need a code or UI example, let me know your exact workflow and agent setup and I can provide a more tailored walkthrough.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[dosubot[bot]]

To pass user input from an agent to the input parameters of a referenced workflow tool in Dify:

1. Define input variables in your workflow's Start Node. These variables become the tool's input parameters when you publish the workflow as a tool. Make sure each variable you want to receive from the agent is explicitly listed in the Start Node's variable configuration. If you update these variables, you must republish the tool to sync the parameter list, or you'll get parameter mismatch errors [source].

2. Publish the workflow as a tool. Dify will expose the Start Node variables as the tool's parameters. These are stored in the tool's configuration and must match the agent's expected input names and types [source].

3. In your agent node (in a chatflow or workflow), add the workflow tool and map the agent's user input to the tool parameters. In the Dify UI, when configuring the agent node, you can bind each tool parameter to a user input variable, a previous node's output, or a constant. The parameter names and types must match exactly; for example, if the tool expects a string, you must pass a string, not a dict [source].

4. Known issues in v1.7.2:

   • There is a bug where dynamic variables (like {{name}}) may not resolve correctly when a workflow is used as a tool in an agent. If you see empty values, this is likely the cause. As a workaround, call the workflow directly (not as an agent tool) to confirm variable passing works [source].
   • Numeric input parameters may not resolve properly in agent nodes in v1.7.2. This was fixed in a later version, so consider upgrading if you need this feature [source].
   • If you see type errors (e.g., "Only basic types and lists are allowed"), make sure your agent is passing the correct type for each parameter. For complex objects, set the parameter type to OBJECT in your workflow tool config [source].

Example minimal flow:

graph LR
    A["User Input (via Agent)"] --> B["Agent Node"]
    B --> C["Workflow Tool"]
    C --> D["Workflow Start Node (inputs)"]

Loading

• User input is collected by the agent.
• The agent node passes mapped values to the workflow tool.
• The workflow tool invokes the workflow, passing parameters to the Start Node.

Troubleshooting tips:

• Double-check that all variables you want to pass are defined in the Start Node and exposed as tool parameters.
• In the agent node UI, confirm each tool parameter is mapped to the correct variable.
• If you change input parameters in the workflow, republish the tool and re-add it to the agent node.
• For dynamic values, ensure the variable exists in both the agent context and the workflow Start Node.

If you need a concrete YAML or UI mapping example, let me know your parameter names and types and I can provide a snippet.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[James-Bond123]

I saw two fields in the workflow tool configuration interface of the intelligent agent, one is the parameter, which is displayed as empty, and the other is the setting. The variable is the display name of the workflow input node, which requires filling in the value. How should I set it here

[dosubot[bot]]

In the agent's workflow tool configuration UI, the "parameter" tab lists dynamic input variables (from your workflow's Start Node) that can be mapped to agent/user input. If it's empty, it usually means your workflow tool wasn't published with explicit input variables, or you haven't republished it after changing the Start Node. To fix this, make sure your workflow's Start Node defines all required input variables, then republish the workflow as a tool so these parameters appear in the agent UI "source".

The "setting" tab shows static tool settings or required workflow input variables. The field labeled with your workflow input (like "网址"/"URL") is where you must provide a value. You can enter a static value (e.g., a specific URL) or reference an agent variable (e.g., a user input variable from earlier in the flow). The "Save" button will stay disabled until you fill in all required fields with valid values "source".

If you want the agent to pass user input to the workflow tool, use a variable reference in the "setting" field (for example, select from the dropdown if available, or type the variable name). This ensures the value entered by the user is passed to the workflow input when the tool runs "source".

If you update your workflow's input variables, always republish the tool and re-add it to the agent node to sync the configuration. If you still see the parameter tab empty after this, double-check your Start Node variable definitions and make sure they match what you expect "source".

Let me know if you want a concrete example of how to reference agent variables in the "setting" field!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[James-Bond123]

Is the operation of mapping user input information to the workflow start node variable completed on the parameter page or the settings page？

[dosubot[bot]]

The mapping of user input to the workflow start node variable is done on the settings page. In your case, since the parameter tab is empty, you should fill in or bind the required input fields (like "网址"/"URL") on the settings tab to the appropriate agent/user input variable. This is how the value gets passed to your workflow when the tool runs. The parameter tab only appears (and is used) for variables of form type "llm", which are automatically filled by the LLM and cannot be manually mapped or edited by you in the UI. For manual mapping, always use the settings tab and ensure your workflow/tool input variables are not of type "llm" if you want this control [source] [source].

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[James-Bond123]

I should fill in or bind the required input fields (like " URL "on the settings tab to the appropriate agent/user input variable. What should I fill in for this agent/user input variable？Is it {{query}}?

[dosubot[bot]]

Yes, in most Dify agent workflows, {{query}} is the default variable for user input—so you should select or enter {{query}} in the settings tab to bind the "URL" field to what the user provides in chat or the agent interface. If you see a variable picker or dropdown, {{query}} will usually be listed there.

If you or your team have customized the agent's input configuration or the workflow's Start Node to use a different variable name (for example, {{url}} or {{website}}), use that name instead. The variable must match what’s defined in both the agent and the workflow Start Node for the value to resolve correctly when the workflow runs.

If you’re unsure, check the available variables shown in the settings tab’s picker—{{query}} is almost always the right choice for standard user input scenarios in Dify v1.7.2 source source source.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[James-Bond123]

The selector in my settings tab does not display the available variables that can be imported, only allowing manual input. Is this a problem?

[dosubot[bot]]

Yes, this is a known issue in Dify v1.7.2. The variable picker in the settings tab should normally show available variables like {{query}}, but in this version, it sometimes doesn't appear—especially for certain input types (like 'Select') or due to frontend bugs in how variables are loaded into the UI. Manual input (typing {{query}}) can still work as long as the variable is correctly defined in both your agent's input configuration and the workflow's Start Node, but the lack of suggestions is not expected behavior and can make setup error-prone. This issue was fixed in later versions (>=1.9.1), so upgrading will restore the variable picker and make variable binding much easier. If you must stay on 1.7.2, double-check your variable names and types, and try reloading or editing the node—sometimes the picker appears after a refresh. For more details, see this discussion and this bug report.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[James-Bond123]

So should I update the version to better map user input variables to the workflow start node?

[dosubot[bot]]

Yes, you should update Dify to at least version 1.9.1 (ideally the latest) to fix the variable picker UI and variable mapping issues. In v1.7.2, the variable picker in the settings tab often fails to show available variables like {{query}}, making it hard to reliably map user input to workflow start node variables. This is a known bug and was resolved in later versions—upgrading restores the variable picker, improves variable binding for all supported input types, and fixes bugs with agent-tool parameter passing and select input binding, making the whole process much more reliable and user-friendly citation citation citation citation.

When upgrading, back up your data, update your Docker images and configs, run database migrations, and check plugin compatibility. If you run into legacy workflow issues after upgrading, you can temporarily restore old parameter handling by setting tool_node_version to null in your workflow/agent node configs citation.

Let me know if you want step-by-step upgrade instructions or run into any migration issues.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[James-Bond123]

I don't know how to upgrade the version. I am dify deployed on Docker under Windows system. Can you tell me the specific operation process for upgrading the version？

[dosubot[bot]]

Here’s how to upgrade your Dify deployment on Docker under Windows:

1. Back up your data: Copy the following folders to a safe location:

   • ./volumes/app/storage (user files)
   • ./volumes/db/data (PostgreSQL)
   • ./volumes/mysql/data (MySQL, if used)
   • ./volumes/redis/data (Redis)
     This protects your data in case anything goes wrong during the upgrade [source].

2. Stop your running containers:
   Open a terminal in your Dify project directory and run:

   docker compose down
   

3. Update your configuration files:

   • Download the latest .env.example and compare it with your .env. Add any new variables and update changed ones, but keep your existing secrets and credentials.
   • If your docker-compose.yaml was generated from a template, regenerate it using the latest template and your updated .env.

4. Pull the latest images:

   docker compose pull
   

   This fetches the newest Dify images.

5. Start the new containers:

   docker compose up -d
   

6. Run migration commands inside the API container:
   These commands update plugins, models, and database schema.

   docker compose exec api bash
   # Inside the container, run:
   uv run flask extract-plugins --workers=20
   uv run flask install-plugins --workers=2
   uv run flask migrate-data-for-plugin
   uv run flask upgrade-db
   exit
   

   If you use MySQL instead of PostgreSQL, make sure your .env reflects that.

7. Check everything is working:

   • Visit your Dify web UI and confirm your data, workflows, and plugins are present.
   • If you see missing plugins or models, repeat the migration commands.

Windows-specific notes:

• Use forward slashes (/) in volume paths in your docker-compose.yaml and .env files.
• If you see file permission errors, you may need to manually adjust permissions on the volumes/app/storage folder. The init_permissions service in the compose file helps with this, but on Windows, permissions are less strict.
• Always use the same PowerShell or CMD terminal you used for your original deployment to avoid path or permission issues.

Tip: Always back up before upgrading. If you run into issues, you can restore your backup and try again.

For more details, see this upgrade guide and discussion and migration PRs.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[James-Bond123]

The update is a bit complicated, and I don't have any data to save on dify right now. I plan to deploy a new dify directly. How should I proceed? Do I need to delete the current version of dify first?

[dosubot[bot]]

You don't need to "delete" the old Dify version, but for a clean install, it's best to stop and remove the old containers and delete the persistent data. Here’s how to do a fresh deployment on Docker under Windows (assuming you have no data to keep):

1. Open a terminal in your Dify project directory.
2. Stop all running Dify containers:

   docker compose down
   

3. Delete the persistent data directory. In PowerShell, run:

   Remove-Item -Recurse -Force .\docker\volumes
   

   (Or use rm -rf docker/volumes in Git Bash.)
4. (Optional) Remove any named Docker volumes if you used them:

   docker volume ls
   docker volume rm <volume_name>
   

5. Download the latest Dify release from GitHub and extract it to a new or empty directory.
6. Copy .env.example to .env and customize as needed for your environment.
7. In your project directory, start Dify:

   docker compose up -d
   

8. Access the web UI to confirm it’s running.

This will give you a brand new Dify instance with no old data or settings. All plugins and workflows will need to be reinstalled and reconfigured. For more details, see the official discussion and guides: discussion 26885, issue 26927, issue 29073.

If you want to use a different directory for your new deployment, you can simply extract the new release there and start from step 6.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[James-Bond123]

Does the latest version of dify fail to parse the HTTP request body of imported OpenAPI specifications when creating custom tools? I didn't see any parameter configuration in the request body when the input on the front-end changed？

[dosubot[bot]]

Dify's backend does parse and support OpenAPI requestBody parameters for custom tools, including handling complex schemas, $ref references, and file uploads—the parameters from the request body should be available for the UI to render as input fields "api/core/tools/custom_tool/tool.py". If you don't see any parameter configuration for the request body on the front-end after importing an OpenAPI spec, it's likely a UI rendering issue or a gap in how the parameters are surfaced from backend to frontend, not a failure in backend parsing.

This can sometimes happen if the OpenAPI schema uses uncommon patterns, or if the requestBody is defined in a way the UI doesn't expect. Double-check that your OpenAPI spec's requestBody uses a standard JSON schema with "properties" and "required" fields. If the schema is valid and you still don't see the fields, it's likely a front-end limitation.

As a workaround, try simplifying your requestBody schema or re-importing the spec. If the problem persists, you may need to wait for a UI update or manually adjust the tool configuration. The backend is designed to support requestBody parameter mapping, so improvements to the UI should eventually resolve this "api/core/tools/entities/tool_bundle.py".

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[James-Bond123]

Does dify support parsing requestBody with content type text/plain in custom tools?