The Waiting for Callback node is used for a Process only.
The Waiting for Callback node pauses the processing of a task until it receives a response. The node is commonly used when a Process must wait for an action from a user. For example, a chatbot waits for user input before it generates a reply. The Waiting for Callback node is similar to the Set State node in that once a task gets into the node, it cannot move on until it is modified in some way or expires. However, unlike the Set State node, there are no conditions to be met for the Waiting for Callback node. As soon as a task is modified, it will exit the node, no matter the change.
You can callback a task by:
- Creating a task manually in the View mode
- Applying the Modify Task node
- Using Corezoid API
- Making a request to Callback URL
Corezoid API vs Request to Callback URL:
- Corezoid API provides a code-based framework for performing UI operations within a specified format. For more information, go to Corezoid API.
- Callback URL is the API request made specifically to the URL provided within the Waiting for Callback node. This method is recommended for replying to tasks from outside Corezoid.
The Waiting for Callback node has the following parameters:
(Optional) Title and Description: Name and details of the node.
API Callback URL:
- Corezoid: Is a Callback URL for an API call.
- Mandrill: Is a legacy feature, a Callback URL that allows you to receive callbacks directly from Mandrill.
- Path to task ID: Shows the task ID of the task you are replying to as one of the parameters of the API Call.
- The checkbox is selected: When updating a task from an external system by using a request to Callback URL and the task isn't in the current node, the task_not_in_current_sync_callback_node value appears as an error.
- The checkbox is cleared: The request is successful even if the task isn't in the current node.
Alert if the number of tasks in the node queue reaches the following number: Helps monitor whether the number of tasks in the node exceeds the specified threshold. When selecting the checkbox, you have to enter the needed number of tasks in the field that appears below.
Maximum interval, for which the task stays in the node before being forwarded: The amount of time a task is allowed to be in the node; can be set in seconds, minutes, hours, and days.
Note: The checkbox has the minimum value as 30 seconds. You can set a shorter interval by using the Unixtime function.
Manually modified task
In the example below, you can see how the task is modified manually.
The Modify button in the task window is available in the Archive tab that opens the New Task dialog.
Task modified in Modify Task node
In the example below, you can see a task modified with the Waiting for Callback node by using the Modify Task node in another Process.
Task modified by Corezoid API
In the example below, a task was modified with Corezoid API by using the Waiting for Callback node.
You can use the following request body with the task_id parameter instead of ref for your requests.
Task modified by Callback URL
In the example below, you can see the task modified by submitting the POST request to the URL provided within the Waiting for Callback node.
Example request is sent in Postman.
Error handling & troubleshooting
When an error occurs during the task processing, you may see the following error parameter names in the task.
|Error parameter name
|Hardware (system error), Software (error in a node logic/settings).
|Error description in human-readable language; can be static or dynamic
tag __conveyor_callback_return_type_tag__ may have the following values.
|The task you are trying to modify from the Modify Task node is not inside the referenced Waiting for Callback node.
|Make sure the task is in the specified node at the moment or clear the Synchronous checkbox in the Waiting for Callback node settings.