Node: Request Form Response

The Request Form Response node invites one or more recipients to respond to a Hashdata form. Unlike a simple email send, this node pauses the workflow execution until the response is received — or until a timeout deadline is reached, if you have configured one. Only after the response (or the deadline expiration) does the flow advance to the next node.

This wait behavior makes the node ideal for processes that depend on information collected in steps, where each step may involve different people or different forms.

When to Use

The Request Form Response node is the right choice whenever the workflow needs to obtain new data from someone before continuing. See the most common scenarios:

• Multi-step collection: the process starts with an initial form and, depending on the responses, triggers new forms for other people or departments. For example, a purchase order can be filled by the requester and then a second form with budget approval data can be sent to the finance manager.
• Additional data: during the workflow execution you identify that you need complementary information not provided in the original form. Instead of restarting the process, simply add a node that requests only the missing data.
• Satisfaction surveys: after completing a service, product delivery, or service provision, the workflow can automatically invite the customer to respond to an NPS survey or quality assessment.
• Approvals with justification collection: in flows that already have an approval node, Request Form Response can be used before or after to collect structured information that supports the decision.

Configuration

To configure the node, click on it in the workflow canvas and fill in the fields in the right side panel:

Field	Description	Required
Form	Select which Hashdata form will be sent to recipients to respond. Only published and available forms in the space appear in this list.	Yes
Recipients	Defines who will receive the invitation to respond to the form. Accepts four recipient types: platform user, trigger form respondent, email field of an ancestor form, or freely typed external email. Multiple recipients can be added.	Yes
Invitation email subject	Text that will appear in the subject line of the email sent to the recipient. Supports variables in the format {{field_name}} to personalize the message with data from previous forms.	Yes
Invitation email body	Main message of the invitation email. Supports rich text formatting, variable insertion, and artifacts. The form access link is automatically included in the email — you don't need to add it manually.	Yes
Timeout (optional)	Maximum deadline for the recipient to respond to the form. Configure a duration (integer) and a time unit (Minutes, Hours, Days, or Weeks). If the deadline is reached without a response, the node activates the TIMEOUT output on the canvas, allowing this scenario to be handled with an alternative flow.	No

Recipient Types

When adding recipients, you can combine different origins in the same configuration:

1. Platform user: select an internal user registered in Hashdata. Useful when the respondent is always a fixed team member.
2. Form respondent: uses the address of whoever responded to the trigger form or another ancestor form in the workflow. Ideal for processes where the same person needs to provide more information.
3. Form email field: references the value filled in an email-type question in a previous form. Allows forwarding the invitation to a contact dynamically provided during the process.
4. External email: directly type a fixed email address. Useful for notifying team inboxes or external partners who are not registered on the platform.

Collected Data

After the recipient responds to the form, all responses become available as variables in subsequent workflow nodes. Simply reference the field name using the {{field_name}} syntax.

For example, if the requested form contains a question called "Contract number", you can use {{Contract number}} in the subject of a subsequent email, in a status definition node, in Slack or Teams messages, or in any other field that accepts variables.

This means that each form collected throughout the workflow enriches the context available for the nodes that come after, allowing emails, approvals, and integrations to be increasingly personalized as the process advances.

Personalize the invitation with trigger form data

Use variables in the subject and email body of the invitation to make the message more relevant to the recipient. For example, if the workflow was started by filling in a request form with the field "Requester name", you can include {{Requester name}} in the email body so the invitee knows who originated the request. This increases the response rate and reduces questions about the context of the request.

The form link in the email is single-use per recipient

Each invitation email generated by this node contains a personalized, single-use link. This link identifies the recipient and associates the response with the correct workflow instance. If the recipient forwards the email to someone else or tries to respond more than once using the same link, the system will not record the second response. If the invitation needs to be resent, use the instance controls on the workflow tracking page.

Handling the Timeout

When the Timeout field is configured, the node has two outputs on the canvas:

• Main output (no label or with the node name): activated when the recipient responds within the deadline.
• TIMEOUT output: activated when the deadline expires without any response having been received.

To correctly handle the timeout, connect the TIMEOUT output to an appropriate handling node. Some common approaches are:

1. Connect the TIMEOUT output to a Send Email node to notify a responsible person that the deadline was reached without a response.
2. Connect the TIMEOUT output to a Set Status node to record that the instance was pending due to lack of response.
3. Connect the TIMEOUT output to an Approval node so a manager can decide how to proceed manually.

Without timeout configured, the workflow waits indefinitely

If you don't configure a timeout, the node will remain waiting for the recipient's response for an indefinite time. The instance will have the status Awaiting form response while the deadline is not defined or while the response doesn't arrive. Make sure to configure a timeout in processes with defined SLAs or that cannot be blocked indefinitely.

Node Outputs on the Canvas

Output	When activated
Main output	The recipient responded to the form within the deadline (or without a defined deadline).
TIMEOUT	The configured deadline was reached without any response being received. Available only when timeout is configured.

Instance Status

While the Request Form Response node is waiting for the recipient's response, the workflow instance displays the status Awaiting form response in the Last step column of the tracking page. This status allows managers and operators to quickly identify which processes are pending an external action.

After the response is received — or after the timeout is activated — the status is updated according to the next node in the flow.

Best Practices

• Formulate objective questions in the requested form. The simpler and more direct the form, the higher the response rate from recipients.
• Personalize the invitation email with the process context. Recipients who understand the reason for the request respond more quickly.
• Always define a timeout in deadline-driven processes, even if generous. This prevents instances from getting stuck indefinitely in case of unread emails or unavailable recipients.
• Handle the TIMEOUT explicitly in the canvas. Workflows that ignore the TIMEOUT output may leave the process in an undefined state for managers and auditors.
• Combine with the Set Status node right after the received response to record process progress in a readable way in the instance listing.