mirror of
https://github.com/langgenius/dify-docs.git
synced 2026-03-26 13:18:34 +07:00
74428d2604
* draft * revise based on hands-on testing * modify based on feedback * add zh and ja translation * Update tip for referencing text output variable Clarify the default behavior of the reasoning model output. * Add translation note Added a note about AI translation accuracy and referenced the English version for discrepancies. * Update human-input.mdx with translation note Add a note about AI translation accuracy and reference to the English version. * Apply suggestion from @Copilot Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update wording for clarity on model output display --------- Co-authored-by: Riskey <riskey47@dify.ai> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
80 lines
3.3 KiB
Plaintext
80 lines
3.3 KiB
Plaintext
---
|
|
title: Human Input
|
|
description: Pause workflows to request human input, review, or decisions
|
|
icon: user-magnifying-glass
|
|
---
|
|
|
|
The Human Input node pauses workflows at key points to request human input before execution continues.
|
|
|
|
When execution reaches this node, a customizable request form is delivered through specific channels. Recipients can provide input, review data, and choose from predefined decisions that determine how the workflow proceeds.
|
|
|
|
By embedding human judgement directly where it matters, you can **balance automated efficiency with human oversight**.
|
|
|
|
<Frame caption="Request Form Example"><img src="/images/human_input_request_form_example.png" alt="Request Form Example" /></Frame>
|
|
|
|
## Configuration
|
|
|
|
Configure the following to define how the node requests and processes human input:
|
|
|
|
- **Delivery method**: How the request form reaches recipients.
|
|
|
|
- **Form content**: What information recipients will see and what they can input.
|
|
|
|
- **User action**: What decisions recipients can make and how the workflow proceeds accordingly.
|
|
|
|
- **Timeout strategy**: How long to wait and what happens if no recipient responds.
|
|
|
|
### Delivery Method
|
|
|
|
Choose the channel through which the request is delivered. Currently available methods:
|
|
|
|
- **Web app**: Displays the request form directly in the web app interface for the current user to respond.
|
|
|
|
- **Email**: Sends an email containing the request link to one or more recipients.
|
|
|
|
<Note>
|
|
The request closes after the first response regardless of delivery method.
|
|
</Note>
|
|
|
|
### Form Content
|
|
|
|
Customize what appears in the request form:
|
|
|
|
- **Format and structure with Markdown**
|
|
|
|
Use headings, lists, bold text, links, and other Markdown elements to present information clearly.
|
|
|
|
- **Display dynamic data with variables**
|
|
|
|
Reference workflow variables to show dynamic content, such as AI-generated text for review or any needed contextual information from upstream nodes.
|
|
|
|
<Tip>
|
|
If you reference the `text` output variable from a reasoning model, the form will display the model's thinking process along with the final answer by default.
|
|
|
|
To show only the answer, toggle on **Enable Reasoning Tag Separation** for the corresponding LLM node.
|
|
</Tip>
|
|
|
|
- **Collect input with input fields**
|
|
|
|
Input fields can start empty or pre-filled with variables (e.g., LLM output to refine) or static text (e.g., example or default values) that recipients can edit.
|
|
|
|
Each input field becomes a variable for downstream use. For instance, pass edited content for further processing or send feedback to an LLM for regeneration.
|
|
|
|
### User Action
|
|
|
|
Define the decision buttons that recipients can click. Each button routes the workflow to a different execution path.
|
|
|
|
For example, a `Post` branch might lead to nodes that trigger content publishing, while a `Regenerate` branch might loop back to an LLM node to revise the content.
|
|
|
|
<Tip>
|
|
Use preset button styles to visually distinguish actions.
|
|
|
|
For example, use a prominent style for key actions like `Approve` and a subtler one for secondary options.
|
|
</Tip>
|
|
|
|
### Timeout Strategy
|
|
|
|
Configure how long to wait for a response before the request expires.
|
|
|
|
If no recipient responds within the set time, the workflow automatically ends unless you define a fallback branch to handle the timeout—for example, send a notification or retry the request.
|