Configure the Data Collection Node

The Data Collection Node is used when a workflow needs to ask the customer for information and save the answer for later use. It can collect details such as a name, email address, phone number, date, number, username, or another business-specific value, validate the customer's reply, and then store the accepted result in the appropriate contact field.

You can add Data Collection as a dedicated Data step from the Workflow toolbar when you want the collection to appear clearly as its own step on the canvas. The same Data Collection capability can also be added as a Data block inside a Message Node when the question naturally belongs within a larger sequence of messages. The configuration follows the same core idea in both cases: ask for a value, decide where it should be saved, validate the answer, and determine what should happen afterward.

The first field is the prompt the customer receives. Write the question naturally, for example:

What's your email?

or:

What is your full name?

When the workflow reaches the Data Collection step, BotSkyrik sends this prompt and waits for the customer's reply before continuing. Unlike a normal text message, the reply is treated as data that needs to be checked and stored.

Under Save Answer To, choose the field where the accepted value should be stored. BotSkyrik lets you save Data Collection answers to either a System Field or a Custom Field.

System Fields are the standard contact fields already understood by BotSkyrik, such as Full Name, First Name, Last Name, Email, Phone, and other built-in contact information. If you are collecting an email address, for example, you can save the response directly to System · Email rather than creating another field for the same information.

Custom Fields are useful when the information belongs specifically to your business, such as budget, service preference, project type, company size, qualification status, or another value you want to retain for that contact.

The field selector combines the available System and Custom Fields in one place, making it easier to choose the correct destination without leaving the workflow.

When a System Field is selected, BotSkyrik also chooses an appropriate validation type where possible. For example, choosing Email naturally pairs with Email validation, while Full Name uses name validation.

The Validate As setting tells BotSkyrik what kind of answer should be accepted. The current validation options include Text, Full Name, First Name, Last Name, Email, Phone Number, Number, URL, Date, Time, Username, and Custom Validation.

Validation is deterministic rather than being left to the AI. This means an email address is checked as an email, a number is checked as a number, and a phone number is checked using predictable validation rules. The AI cannot simply decide that an invalid value is acceptable.

For example, if the node is configured to collect an email address and the customer sends something that is not a valid email, BotSkyrik does not save that value as the contact's email. Instead, it asks the customer to correct the answer according to the retry settings.

Name collection also performs useful normalization. A response such as “My name is Noor Hussain” can be cleaned into the actual name rather than saving the entire sentence. When Full Name, First Name, or Last Name is collected, BotSkyrik keeps the related name values synchronized for later workflow use.

When Text is selected, BotSkyrik provides Basic and Advanced modes.

Basic is designed for normal conversational data collection. It automatically removes common filler wording and rejects replies that clearly do not contain meaningful text. This is useful for general answers where you want clean text without writing custom validation logic.

Advanced allows custom JavaScript validation when a workflow requires a very specific rule. The validator receives the customer's input and the current workflow context and returns whether the answer should be accepted, along with the value that should be stored or a message explaining why the customer should try again.

The Retries & Fallback section controls what happens when the customer provides an invalid answer.

Set Max retries to determine how many opportunities BotSkyrik should give the customer to provide a valid response. When an answer fails validation, BotSkyrik returns a short validation message and waits for another reply rather than saving incorrect information.

If the customer still does not provide a valid answer, the If it still fails setting decides what happens next. You can continue to the next step, follow a separate Failure path, stop the collection, or assign the conversation to a teammate for human assistance.

The Failure path is useful when you want to handle unsuccessful collection separately. For example, after repeated invalid email attempts, you could route the customer to a message explaining another way to contact the business rather than continuing through the normal successful path.

If Assign to teammate is selected, you can choose a workspace member. After the unsuccessful attempts are exhausted, BotSkyrik assigns the conversation to that person and pauses AI so a human can take over.

Data Collection also includes an On Reply Actions path. This is separate from the normal Next Step and is designed for tasks that should run immediately after a valid answer has been received.

For example, after collecting a valid email address, you may want to apply a tag, update another contact field, or send the collected information to a connected integration. Connect the On Reply Actions output to an Action step when such processing is required.

The important distinction is that the reply action does not replace the workflow's normal continuation. BotSkyrik can run the connected Action after the answer is successfully collected and then continue through the Data step's normal Next Step path.

This keeps data processing separate from the main customer journey. The workflow can save the answer, perform any required business action, and then continue naturally without forcing those operations into the same node.

Sometimes the customer never answers the question at all. The If the contact does not reply section lets you decide whether BotSkyrik should simply keep waiting or follow a separate No Reply path after a timeout.

No Reply handling is disabled by default. If you enable Follow No Reply path after timeout, choose how long BotSkyrik should wait using minutes, hours, or days. You can then connect the No Reply output on the Data node to another workflow step.

A common example is connecting No Reply to a Message Node containing a reminder. If the customer answers before the timeout expires, the timer is cancelled and the workflow continues through the normal successful path. If no answer arrives, BotSkyrik follows the configured No Reply path instead.

This makes follow-up logic part of the Data Collection step itself rather than requiring a separate automation just to check whether somebody responded.

Keep in mind that follow-up delivery still depends on the messaging rules of the selected channel. A workflow can schedule a No Reply path, but the actual follow-up must still be allowed by that channel's messaging policies when the timeout is reached.

After an answer passes validation, BotSkyrik stores the normalized result in the selected field and makes it available to later workflow steps.

For example, an email collected here can later be inserted into a Message, evaluated by a Condition, sent through an Action, used in a booking field mapping, or passed to another supported part of the workflow.

Because the value is stored as contact data rather than being confined to the original message, it can continue to be useful beyond the Data Collection step itself.

This is especially important when building longer qualification or onboarding flows. You can collect different pieces of information at different stages and then use those saved values to personalize or control the rest of the journey.

Use the dedicated Data Node when collecting information deserves its own visible step on the canvas. This is usually the clearest choice for important information such as email addresses, phone numbers, qualification details, or other values that affect later routing.

Use a Data block inside a Message Node when the question is simply one part of a larger conversational sequence and keeping the content together makes the workflow easier to understand.

Both approaches use the same underlying Data Collection system. The choice is mainly about how you want to organize and read the workflow.

A well-configured Data Collection step therefore has four clear responsibilities: ask the question, save the answer in the correct field, validate what the customer sends, and define what happens when the answer succeeds, fails, or never arrives. Once those pieces are configured, connect the appropriate outputs to the next parts of the workflow and continue building the customer journey.