Approval Node
The Approval node requests human input before continuing workflow execution. This node enables human-in-the-loop scenarios where automated processes require manual review, validation, or decision-making. When triggered, it pauses the workflow and displays an approval dialog to the user in the chat interface.
The Approval node belongs to the Human in Loop category and supports two interaction modes: simple binary decisions and structured form submissions.
How It Works
When the workflow reaches an Approval node, execution pauses and the current state is saved automatically. An approval request then appears in the user's chat interface, displaying the configured title and description along with the appropriate input controls.
The user reviews the request and provides their input by clicking approve/reject buttons or submitting form data. Once the user responds, the workflow resumes and stores the response in the specified output variable. Downstream nodes can then access this approval response data for conditional logic or further processing.
The approval dialog remains active until the user responds. If the user closes the chat or navigates away, the workflow stays paused and resumes when they return and submit a response.
Configuration
Approval Type
Determines the interaction mode for user input.
| Type | Description |
|---|---|
| Binary | Displays simple approve/reject buttons. Use for straightforward yes/no decisions. |
| CustomForm | Displays a form with multiple input fields. Use when structured data is needed from the user. |
Title
The heading displayed at the top of the approval dialog. Accepts fixed text or an expression that evaluates at runtime. For example, "Review Document Classification" or a dynamic expression referencing workflow variables.
Description
Instructions or context shown to the user below the title. Provide clear guidance on what action the user should take and any relevant background information. For example, "Please review the extracted entities and confirm they are correct before proceeding with the redaction process."
Binary Configuration
These options appear when Approval Type is set to Binary.
Approve Button Label
Text displayed on the positive action button. Default value is "Approve". Common alternatives include "Confirm", "Accept", or "Yes, Proceed".
Reject Button Label
Text displayed on the negative action button. Default value is "Reject". Common alternatives include "Decline", "Cancel", or "No, Stop".
Approve Button Style
Visual appearance of the approve button. Available styles:
btn-success- Blue button (default, recommended for positive actions)btn-primary- Orange buttonbtn-info- Light blue button
Reject Button Style
Visual appearance of the reject button. Available styles:
btn-danger- Red button (default, recommended for negative actions)btn-secondary- Gray buttonbtn-warning- Yellow button
Fail On Reject
When enabled, the workflow fails and stops execution if the user clicks reject or closes the approval dialog without responding. When disabled, the workflow continues with the rejection recorded in the output variable.
Enable this option when rejection should terminate the entire workflow. Disable it when rejections need to be handled with conditional logic downstream.
Custom Form Configuration
These options appear when Approval Type is set to CustomForm.
Form Controls
Define the input fields displayed in the form. Each field includes:
| Property | Description |
|---|---|
| Field Type | Input control type: Text Box, Text Area, Dropdown, Checkbox, Checkbox List, Radio, Date, or Number |
| Field Key | Unique identifier for the field value in the response data (e.g., priority, feedback, approved_items) |
| Label | Text displayed above the field |
| Placeholder | Hint text shown inside empty fields |
| Required | When enabled, the user must complete this field to submit the form |
| Help Text | Additional guidance displayed below the field |
Use Add Field to include additional form controls. For field key naming, use lowercase letters, numbers, and underscores. The key becomes the property name in the response object stored in the output variable.
Submit Button Label
Text displayed on the form submission button. Default value is "Submit".
Submit Button Style
Visual appearance of the submit button. Default is btn-primary (blue).
Fail On Reject
Same behavior as binary configuration. The form includes a cancel option that triggers rejection behavior.
Output Field
Specifies the workflow variable where the approval response is stored. If the variable does not exist, it is created automatically. Default variable name is approval_result.
Binary response structure:
{
"approved": true
}
CustomForm response structure:
{
"fieldKey1": "value1",
"fieldKey2": "value2"
}
Downstream nodes can use this output to branch logic based on approval status or access submitted form values.
Execution Lifecycle
The Approval node begins when it receives input from upstream nodes. Workflow execution then pauses while the state is checkpointed to preserve progress.
The approval dialog renders in the user's chat interface with the configured title, description, and input controls. The node waits for user response, with an optional timeout if configured.
Once the user submits approval, rejection, or form data, the workflow resumes with the response stored in the output variable. The output then flows to connected downstream nodes for further processing.
Usage Example
A document processing workflow extracts sensitive information and requires human verification before redaction. After the extraction step, an Approval node with Binary type displays the title "Verify Extracted Entities" and a description showing the detected entities from the extraction results.
The approve button is labeled "Proceed with Redaction" and the reject button shows "Cancel Process". With Fail on Reject enabled, rejecting the request stops the workflow entirely. The response is stored in the verification_result variable.
A downstream Condition node checks verification_result.approved to route approved requests to the Redaction node while handling any edge cases appropriately.
Constraints and Limitations
- Single responder: Only the user who initiated the chat session can respond to approval requests.
- No concurrent approvals: Multiple Approval nodes in parallel branches execute sequentially when reached.
- Session persistence: Users must maintain their chat session to respond. Approval state persists if the user navigates away and returns.
- Form validation: CustomForm validates required fields client-side. Complex validation logic requires downstream nodes.
Best Practices
- Write clear, actionable descriptions that tell users exactly what they are approving
- Use binary approvals for simple yes/no decisions; reserve CustomForm for collecting structured feedback
- Enable Fail on Reject when rejection should stop the workflow entirely
- Choose button labels that clearly indicate the action outcome (e.g., "Delete Permanently" instead of "Yes")
- Store approval responses in descriptively named variables for easier downstream reference
- Consider adding a preceding node that summarizes the context before requesting approval
Related Articles
- Condition node - Branch workflow based on approval response
- User Prompt node - Collect freeform text input from users
- Loop node - Iterate approval requests for batch processing