Configure the Message Node

The Message Node is where you create the messages a customer receives while moving through a workflow.

A Message Node can contain much more than a single line of text. You can personalize messages with contact data, add interactive replies, insert media and other content blocks, and combine multiple pieces of content inside the same node.

The exact options available can vary slightly depending on the workflow channel because WhatsApp, Telegram, Instagram, and Messenger each have their own messaging capabilities and limits.

Open a Message Node and begin with the Text block.

This is the main message the customer receives. You can write normal conversational content just as you would in a direct message.

For example, an appointment confirmation might include:

🎉 Your Consultation Is Confirmed!

followed by the appointment date, time, and any additional instructions for the customer.

The character counter at the bottom of the editor shows how much text is currently being used and the maximum supported for the selected channel.

BotSkyrik automatically applies the appropriate message limit for the workflow channel.

Current text limits include:

• WhatsApp: up to 4,096 characters

• Telegram: up to 4,096 characters

• Messenger: up to 2,000 characters

• Instagram: up to 1,000 characters

The Variables button allows you to insert stored information directly into the message.

Instead of manually typing variable syntax, place the cursor where the information should appear and select the value you want from the variable picker.

For example, an appointment confirmation can use values such as:

{{appointment_start}}

or

{{appointment_timezone}}

When the workflow runs, BotSkyrik replaces the variable with the value available for that contact or workflow run.

This allows one Message Node to send personalized content to different customers without creating separate messages for each person.

System Fields

System Fields are built-in contact fields provided by BotSkyrik.

These represent standard information the platform already understands, such as supported contact identity and profile information.

System Fields are managed by BotSkyrik and do not need to be created manually.

When you need one inside a message, open Variables, choose System Fields, and select the field you want to insert.

The available System Fields may depend on the selected channel and the contact information available through that channel.

Custom Fields

Custom Fields are workspace fields that you create for information specific to your business.

For example, you might create fields for a customer's plan, qualification status, preferred service, project type, budget, or any other information your workflow needs to remember.

You can create and manage Custom Fields from the Workflow area, but you do not need to leave the Message Node when you realize a new one is required.

Open Variables → Custom Fields and choose Create new field.

Once created, the field becomes reusable across your workspace and can immediately be inserted into the message.

This makes it easier to build a workflow without repeatedly leaving the builder just to prepare fields.

Workspace Fields

There is an important channel difference to understand.

Messenger

Messenger allows BotSkyrik to configure Buttons and Quick Replies together in the same Text block.

That is why the screenshot above shows both sections side by side:

Quick Replies

and

Buttons

You may use one type, the other type, or both when building a Messenger message.

Instagram, WhatsApp, and Telegram

For these channels, BotSkyrik treats Buttons and Quick Replies as mutually exclusive inside the same Text block.

You can configure either:

Quick Replies

or

Buttons

but you do not add both types to that same Text block.

The editor automatically follows this rule based on the workflow channel, so you do not need to manually remember the platform behavior while building the workflow.

This is especially useful when the same Workflow Builder is used across different channels because the interface adapts to the selected channel's capabilities.

A Message Node is not limited to one Text block.

Scroll below the current message and you will find Add Content Block.

This allows several pieces of content to be placed inside the same Message Node and delivered in sequence.

Depending on the selected channel, you may see blocks such as:

Text — send another text message.

Media — add an image, video, PDF, or audio where supported.

Gallery — create a swipeable set of images with interactive elements on supported Messenger and Instagram experiences.

Dynamic Reply — retrieve live information through an existing Custom Action and use the returned result in the conversation.

Data — ask the customer for information and save the answer.

Delay — insert a short pause between pieces of content inside the message sequence.

List — display a selectable list menu on channels that support it, currently including WhatsApp.

Not every block appears on every channel. BotSkyrik automatically shows the content types appropriate for the selected workflow channel.

This allows a single Message Node to represent a small conversational sequence instead of requiring a separate canvas node for every individual message.

Some capabilities are available both as part of a Message Node and elsewhere in the Workflow Builder.

For example, Media and Data Collection can be used as content inside a Message Node while also having dedicated workflow entry points for situations where you want them to stand more clearly on the canvas.

We will explain those capabilities in their own dedicated guides rather than repeating their complete configuration here.

Other Message-specific blocks, including Dynamic Reply, will be covered as we continue through this Message Node guide.

After adding a Button, enter the label you want the customer to see and then click the arrow/action icon shown on the right side of the Button row.

This opens the Button configuration panel. BotSkyrik deliberately separates Button behaviour into two parts: When Tapped controls what should happen immediately when the customer presses the Button, while Then Continue controls where the workflow should go afterward. These are independent settings, which means a Button can perform an action and still continue through the workflow.

A newly created Button already works without additional configuration. By default, Nothing extra is selected under When Tapped and Next step is selected under Then Continue. In that state, tapping the Button simply follows the normal connector from the Message Node. If that is all you need, you can connect the next node visually on the canvas and leave the Button configuration unchanged.

If you choose Open Website, BotSkyrik displays a Website URL field where you can enter any valid external destination. This can be a normal website page, product page, form, payment page, booking page, or another external service. When the customer taps the Button, BotSkyrik opens that address directly. This is useful when all you need is a clickable destination, but for booking and voice experiences BotSkyrik also provides dedicated options that offer deeper integration with the rest of the platform.

Choose Book Appointment when the Button should open a booking experience from a scheduling provider already connected to BotSkyrik. If a scheduler has not been connected yet, the user can first visit Integrations and connect the provider there. Once the integration is available, the Button editor can load the supported booking provider and its actual event types so you do not need to copy and paste a booking URL manually.

The advantage of using the dedicated Book Appointment option is that BotSkyrik can keep the booking linked to the workflow and conversation. A normal website link only sends the customer somewhere; it does not necessarily tell BotSkyrik whether the customer actually completed the booking. With a connected scheduling provider, BotSkyrik can also receive booking events such as a confirmed appointment, a reschedule, or a cancellation and use those events as Workflow Triggers.

This makes it possible to create a complete journey. The customer can tap the booking Button, complete the appointment on the scheduling page, and then BotSkyrik can react when the booking provider reports that the appointment was actually created. A confirmation workflow can then begin from the real booking event rather than assuming that a Button click means a booking was completed.

For supported booking experiences, BotSkyrik can also map information already collected in the workflow into the booking form. In the Cal.com example shown in the screenshot, the Booking Field Mapping section displays the questions visible on that booking form and allows you to connect them to existing BotSkyrik fields.

If the workflow has already collected the customer's name and email, those values can be mapped to the matching booking questions instead of asking the customer to enter the same information again. BotSkyrik can use System Fields, Custom Fields, or suitable values already collected in the workflow, and the Auto-map matching fields option can connect obvious matches automatically.

Besides making the booking process faster for the customer, this also helps keep contact information consistent. Without mapping, a customer might provide one email address during the conversation and another when booking, which can make it more difficult to match the booking back to the original contact. Mapping reduces that problem by carrying the information already collected in BotSkyrik into the booking experience.

Only appropriate information should be mapped into booking URLs. Sensitive information such as passwords, medical records, financial details, or other private data should not be exposed through prefilled booking parameters.

The availability of real-time booking events also depends on the scheduling provider and plan being used. Cal.com currently offers webhook capabilities on its individual free plan, while Calendly's webhook subscriptions require an eligible paid plan. These external provider policies can change over time, so the important principle inside BotSkyrik is to use the connected booking option whenever the workflow needs to know about the actual booking event rather than only the initial Button click.

The Button can also start a Voice Conversation using the Voice capability already configured in BotSkyrik. The Voice configuration itself lives under AI Actions, so the business owner configures that capability once and can then use it from workflows.

After configuring what happens when the Button is tapped, the Then Continue section determines where the workflow should go afterward. Next step follows the normal connector from the current Message Node and is the default behaviour. Choose existing step lets the Button jump directly to another node that already exists in the same workflow. Start Another Flow launches another published automation, allowing a reusable workflow to be started instead of rebuilding the same sequence again. End the flow stops the workflow on that Button path.

The important point is that the immediate action and the continuation are separate. A Button can open a website and still continue to another workflow step, or it can open the tracked booking experience and then route the workflow somewhere specific. Connecting a node on the canvas does not remove the Button action that has already been configured.

If you scroll further down inside the same Message Node, you can add a Gallery block from the Add Content Block area. The Gallery block is used when you want to show multiple visual cards inside the conversation instead of sending only plain text or a single media item. This is especially useful for showcasing products, services, portfolio items, featured offers, or any situation where the customer should be able to browse several options in one place.

When you open the Gallery block, BotSkyrik allows you to add between 2 and 10 images. Each image becomes its own gallery card. You can add a new image, replace an existing one, paste an image URL, and reorder the cards if you want to change the sequence in which they appear. This is helpful when the order matters, such as showing a featured service first or arranging products in a preferred display order.

For each gallery card, BotSkyrik currently lets you configure a Title, an optional Subtitle, and an optional Card Link. In the current builder, both the Title and Subtitle support up to 80 characters, which gives enough room for a short heading and a clear supporting description without making the card too heavy.

The Title is the main label of the card and should usually be short and clear. The Subtitle is optional and can be used to briefly describe the item, service, or offer shown in the image. The Card Link is also optional, but it becomes very useful when you want the card itself to be clickable. If a link is added, tapping that card opens the provided URL.

This means the Gallery block is not just for decoration. It can also guide the customer to a product page, service page, booking page, offer page, or any other destination you want them to open after tapping a card. If no link is provided, the card can still serve as a visual presentation item inside the conversation.

The strength of the Gallery block is that it keeps everything inside the same Message Node. Instead of sending several separate images one by one, you can present a structured visual selection in a cleaner and more interactive way. It also helps when you want the customer to compare options quickly without scrolling through many separate messages.

As with other content blocks, the Gallery option only appears where it is supported for the selected workflow channel. If the chosen channel does not support gallery-style presentation, BotSkyrik will not offer this block there. Where it is supported, the Gallery block gives you a compact way to combine visuals, short descriptions, and clickable destinations inside one part of the workflow.

The Dynamic Reply block lets a Message Node retrieve live information from an external API and immediately use the returned result as part of the customer conversation. The API itself is not configured inside the workflow. Instead, BotSkyrik reuses an existing Custom Action that has already been created at the workspace level, so the endpoint, HTTP method, headers, authentication, request body, response settings, and other API configuration stay in one central place.

To use Dynamic Reply, first create and enable an HTTP Custom Action from Custom Actions. When you return to the Message Node and add the Dynamic Reply block, the Custom Action dropdown shows the enabled HTTP actions available in the same workspace. Select the action you want to run, and BotSkyrik will execute that action whenever the workflow reaches this block.

This approach is useful because the same Custom Action can be reused in several parts of BotSkyrik without rebuilding the API connection each time. An AI Agent can use it as one of its available capabilities, a Dynamic Reply can use it to produce a customer-facing message, and an External Request inside a workflow can use it for background processing. The API configuration remains global while each place decides how the returned information should be used.

When Dynamic Reply runs, BotSkyrik builds the request using the current workflow and contact context. Values already available to the conversation, including supported System Fields, Custom Fields, and workflow variables, can therefore be used by the Custom Action when its configured request is executed.

The Response format setting controls how BotSkyrik should turn the external response into the message sent to the customer.

With Auto — send the full reply, BotSkyrik uses a response that is already suitable for messaging. This can be simple text or a supported structured response containing message content. Dynamic responses can also include supported media or gallery content where the selected channel allows it, so the external service is not limited to returning plain text.

If the API returns a larger JSON object and only one particular value should be shown to the customer, choose Text from JSON path instead. You can then specify the path to the required value, such as $.data.reply, and BotSkyrik sends that selected text rather than exposing the complete API response.

This makes Dynamic Reply suitable for both simple APIs that already return a ready-to-send answer and more traditional APIs that return larger structured JSON responses.

A Dynamic Reply can also make returned values available to later workflow steps when the selected Custom Action has Response Mapping configured.

For example, suppose an API returns a product name, price, and availability. The Custom Action can map those returned values, and Dynamic Reply can make them available to the current workflow run. A later Message, Condition, or Action can then use those values instead of calling the API again.

The optional Variable prefix helps keep these returned values organized. If the Custom Action maps a field called price and you enter product as the prefix, that value becomes available to later workflow steps as something like {{product_price}}. This is particularly useful when a workflow calls more than one external service and you want to avoid similarly named values becoming confusing.

The prefix does not change the API itself. It only controls how mapped values from this Dynamic Reply are named inside the current workflow run.

External services can sometimes be unavailable, return an unexpected response, or fail to provide the value your workflow expects. The Fallback message is what the customer receives in that situation.

For example, you might use:

“Sorry, I couldn't retrieve that information right now. Please try again shortly.”

BotSkyrik uses the fallback instead of exposing a raw API error or technical response to the customer. It can be used when the selected Custom Action is unavailable or disabled, when the HTTP request fails, or when the returned response cannot be converted into the configured reply format.

Execution details are also recorded with the selected Custom Action, so failed or successful Dynamic Reply requests can be investigated from the Custom Action's logs rather than troubleshooting blindly inside the Message Node.

Dynamic Reply and External Request can use the same Custom Action, but they serve different purposes.

Use Dynamic Reply when the API result should become part of the conversation immediately. The workflow reaches the block, runs the Custom Action, receives the result, and sends the appropriate reply to the customer.

Use External Request when the workflow needs to call an external service in the background without automatically sending the returned response as a customer message. In that case, mapped values can be stored in the current workflow run and used by later Message, Condition, or Action steps.

The AI Agent uses the same shared Custom Action in another way: rather than executing it because a fixed workflow step was reached, the Agent can choose the Action when the customer's request makes that capability relevant.

This shared architecture means you configure the external system once and then reuse it wherever it is needed, while BotSkyrik controls whether the result is used by the AI Agent, sent directly through a Dynamic Reply, or processed silently by an External Request.

The Delay content block is useful when several pieces of content are being sent from the same Message Node and you do not want them to arrive instantly one after another. Add the Delay block between two message blocks and choose a pause from 1 to 30 seconds. When the workflow reaches that point, BotSkyrik waits for the configured time and then continues with the next content block in the same Message Node.

Where the selected channel supports it, you can also enable Typing during the delay. This makes the pause feel more natural because the customer can see a typing indicator before the next message arrives. BotSkyrik currently enables this option on supported WhatsApp, Telegram, and Messenger conversations; if typing indicators are not enabled for the selected channel, the control is unavailable automatically.

This short Delay should not be confused with the standalone Wait node on the workflow canvas. The inline Delay is designed for conversational pacing between messages and is intentionally limited to a few seconds. The standalone Wait node is used when the workflow needs a real automation delay, such as waiting much longer, continuing at a particular time, or working with more advanced timing rules. We will cover the standalone Wait node separately.

When the workflow channel is WhatsApp, the Message Node also provides a List block. A WhatsApp List is useful when the customer needs to choose from more options than would fit comfortably into ordinary reply buttons. Instead of displaying every option directly in the conversation, WhatsApp shows a Button such as View options, and tapping it opens the organized list.

The List block is built as one complete WhatsApp message. At the top, you can add an optional Header, write the main List body, and add an optional Footer. The current limits are 60 characters for the Header, 1,024 characters for the body, and 60 characters for the Footer. These fields also support the same variable insertion controls used elsewhere in the Workflow Builder, so information already available to the workflow can be included dynamically.

Below the message content is the List Button. This is the text the customer taps to open the available options, for example View options or Choose a service, and it supports up to 20 characters.

The actual choices are created under List Options. BotSkyrik allows up to 10 rows in total, and those rows can be organized into as many as 10 sections. The 10-row limit applies across the complete List rather than separately to each section, so if one section contains six options, only four more rows remain for the other sections.

A section title is optional and supports up to 24 characters. Each option inside the section has a required title of up to 24 characters and an optional description of up to 72 characters. This gives you enough room to keep the option itself short while adding a little more context underneath it when necessary.

For example, a service menu could use a section called Our Services and contain options such as Residential Lighting, Commercial Lighting, and Permanent Lighting, with a short description beneath each one. If the list contains different kinds of choices, you can create additional sections to keep them organized instead of presenting one long unstructured menu.

You can also reorder individual options, add or remove sections, and collapse larger sections while working in the editor. Collapsing a section only makes the builder easier to manage; it does not change what the customer receives.

A List option is not merely text displayed to the customer. Each row behaves as an interactive workflow choice. When the customer selects an option, BotSkyrik identifies the selected row and continues through the path connected to that choice.

On the workflow canvas, the Message Node exposes the List choices as separate List row outputs. You can connect those outputs to different nodes, allowing each selection to lead somewhere different.

For example, one List could offer several services. Selecting Residential Lighting could continue to one branch, while Commercial Lighting could lead to another. This allows a single WhatsApp List to act as a compact menu for several customer journeys without filling the chat with a large number of visible buttons.

If BotSkyrik receives a response that does not correspond to one of the valid List options while the workflow is waiting for a selection, the List remains the active interaction rather than silently moving the customer to an unrelated step.

The List block is offered only when the selected channel supports this native message type. In the current Workflow Builder, it is available for WhatsApp. Other channels use their own supported interactive formats, such as Buttons, Quick Replies, or Gallery experiences, rather than pretending to support a WhatsApp-style List where the channel does not provide one.