Named variables in WhatsApp templates: clearer messages and easier configuration

WhatsApp templates integrated with wolkvox now support variables in a named parameter format. This makes it possible to identify each data field using a descriptive name, for example:

{{customer_name}}
{{document}}
{{interview_date}}
{{interview_time}}

This format complements the traditional positional structure, in which variables are identified only by their order:

{{1}}
{{2}}
{{3}}

With named parameters, each value is explicitly associated with the information it must replace. Therefore, when using the template from wolkvox Agent, the agent can easily identify which value must be entered for each variable without having to memorize its position within the message. For example, a template may include the following content:

Hello, {{candidate_name}}:
This is {{recruiter_name}} from the {{company_name}} Recruitment Team.
We would like to invite you to an interview on {{interview_date}} at {{interview_time}} via {{interview_method}}.

This functionality is compatible with the different template types supported by the WhatsApp connectors integrated with wolkvox Manager, including text templates and templates containing multimedia elements such as images, videos, or documents.

Benefits

• Greater clarity when completing templates: Variable names directly indicate which information the agent must enter. For example, {{customer_name}} is easier to interpret than {{1}}.
• Fewer data replacement errors: The explicit association between the variable and its content reduces the risk of entering values in the wrong order or leaving information incomplete.
• Easier template management: Teams can review and maintain messages with multiple variables without constantly checking the order defined for each parameter.
• Improved scalability: The named format makes it easier to build extensive templates for processes such as sales, collections, customer service, confirmations, recruitment, and transactional notifications.
• Compatibility with different formats: Named variables can be used in templates supported by the WhatsApp integration, including those with multimedia headers, links, and other supported components.

How to create and use a template with named variables

Log in to Meta WhatsApp Manager and go to the template management section. Start the process of creating a new template and complete its general configuration. 

1. In the “Content” section, locate the “Variable type” field and select the “Name” option. 
   • This selection determines that the template variables will be identified using descriptive names instead of consecutive numbering. 
2. In the “Text” field, write the message that will be sent to the customer.
   • Whenever you need to add dynamic data, click “Add variable.” Meta will insert an empty structure: {{}}
   • Inside the braces, enter the name that will identify the information. For example: {{customer_name}}
     {{presentation_type}}
3. The preview displayed on the right will show how the template will be structured.

• Enter sample values so Meta can validate the content and properly review the template before approval.
• The defined names must remain consistent so that each value is associated with the corresponding variable.
• Once the content has been configured, submit the template for review in Meta and wait for it to be approved before using it in the operation.
• After creating, modifying, or approving a template in Meta, you must run template synchronization from wolkvox Manager.
  • This step is necessary for the updated version to become available in wolkvox Agent and in Routing Point flows that use WhatsApp templates.

When an agent needs to send a WhatsApp message using a template:

• Select the corresponding template.
• Review its content and multimedia elements, when applicable.
• Enter one value for each named variable in the “One line per variable” section.
• Complete any links or additional components included in the template.
• Click “Send message.”

The values must be entered in the order in which the variables appear in the template. However, thanks to their descriptive names, the agent can more easily identify which information corresponds to each line.

Enable visual SLA alerts to prioritize unattended chats

wolkvox Manager includes a new setting that enables visual response SLA alerts for chat conversations handled by agents.

When this functionality is enabled, the system displays a traffic-light indicator with a timer in the wolkvox Agent conversation inbox. This indicator makes it possible to quickly identify how long a chat has remained unattended and helps prioritize conversations that require a more urgent response.

The alerts use three visual statuses:

• Green: from 0 to 2 minutes.
• Yellow: from 2 to 5 minutes.
• Red: more than 5 minutes.

This setting is configured globally from the Web Chat section and is automatically reflected in the agents’ inbox.

Benefits

• Conversation prioritization: Makes it possible to immediately identify chats that have been waiting longer for a response, helping agents handle the most critical conversations first.
• Greater control over SLAs: Provides a visual reference of the time elapsed without attention and helps the operation meet its response objectives.
• Preventive monitoring: Reduces the risk of a conversation being overlooked or exceeding the expected response time.
• Improved customer experience: Encourages more timely responses and reduces wait times across chat channels.
• Centralized configuration: The administrator can enable or disable the functionality from wolkvox Manager without making individual changes for each agent.

How to enable response SLA alerts

1. Log in to wolkvox Manager. Click the “Settings” button, identified by the gear icon in the upper-right corner.
2. Go to the “Omni Channel” tab.
3. Select the “Web Chat” subtab.
4. In the upper-right corner of this section, click the button with the three vertical dots icon to open the general chat settings.

• Scroll through the window until you find the “RESPONSE SLA ALERTS” section. 
• Enable the corresponding switch. Once enabled, the system will display the visual traffic-light indicator in the wolkvox Agent inbox.
• Click “Save” to save the configuration.

Once the change has been saved, agents will be able to see the time and color labels next to active conversations.

Use the same SSO to access multiple operations hosted on the same server

wolkvox Manager includes an improvement to Single Sign-On (SSO) management: it is now possible to associate the same SSO identifier with a user across different operations hosted on the same server.

Previously, when an organization managed several operations on the same server, an employee had to register a different email address for each operation. This resulted in duplicate accounts, greater administrative complexity, and a fragmented login experience.

With this update, the user can use the same corporate credentials to access every operation in which they have an enabled account. The administrator only needs to register the same email address in the SSO field when creating the user in each corresponding operation.

In addition, the users table now includes an SSO column, which makes it possible to quickly view the identifier associated with each account.

This functionality unifies access only between operations hosted on the same server.

Benefits

• Simplified identity management: Prevents the creation of multiple email addresses or identities for the same employee who needs access to different operations.
• Centralized administration: Simplifies user creation, deactivation, and modification because the IT team can maintain a single corporate identifier for SSO access.
• Fewer support requests: Reduces issues related to duplicate accounts, forgotten credentials, lockouts, and access resets.
• Unified login experience: The user can use the same corporate identity across all enabled operations on the server without managing different credentials for each one.
• Greater administrator visibility: The new SSO column makes it possible to verify from the user list which email address or identifier is associated with each account.

New Sentinel Component for automating scheduled tasks in wolkvox Studio

wolkvox Studio includes the new Sentinel Component, also known as Sentinel Cron, a tool that makes it possible to schedule and automatically execute recurring tasks within a Routing Point.

Unlike flows that begin with a user action, such as a call, chat, or incoming interaction, the Sentinel Component works as an internal timer. Once configured, it automatically starts the route connected to the component according to the interval, days, schedule, and time zone defined by the administrator.

This functionality makes it possible to add several Sentinel components within the same Routing Point and configure each one with an independent schedule. This allows multiple timed flows to run in parallel without creating separate structures for processes that share the same context or business logic.

The Sentinel Component is available exclusively in Agentic Engine Routing Points.

Benefits

• Concurrent automation: Makes it possible to centralize different scheduled processes in a single Routing Point and run them in parallel using multiple Sentinel components.
• Scheduling flexibility: Offers different execution intervals, ranging from every five minutes to every 24 hours, to adapt automation to the frequency required by each process.
• Control over days and schedules: The Active Window section makes it possible to restrict execution to specific days and time ranges, preventing the flow from running outside the authorized period.
• Time zone accuracy: Makes it possible to explicitly select the time zone used to calculate executions, simplifying the management of operations distributed across different countries.
• Fewer scattered configurations: Reduces the need to create multiple independent Routing Points for related scheduled tasks, making flows easier to organize and maintain.
• Greater operational autonomy: Administrators can configure periodic automations directly from wolkvox Studio without requiring a user to initiate an interaction to activate the process.

What can the Sentinel Component be used for?

The component can be used to automatically start different operational processes, for example:

• Periodically retrieve information from external systems.
• Synchronize data between platforms through integrations or MCP connectors.
• Run automatic follow-ups on records, requests, or customers.
• Validate business conditions at defined intervals.
• Generate scheduled alerts or notifications.
• Start recurring information update, classification, or analysis processes.
• Execute actions only during the operation’s business hours.
• Schedule different processes within the same Routing Point, each with its own frequency and active window.

The final scope of each automation will depend on the components connected after the Sentinel Component and the logic designed in the flow.

How to configure the Sentinel Component

1. Locate the Sentinel Component icon in the upper toolbar and add it to the design canvas.
2. Double-click the component with the left mouse button to open its configuration panel on the right side of the interface.
3. Configure the following fields: 
   • In the “Time Zone” field, select the location that will be used as the reference for executing the flow. This selection determines the local time used to evaluate the interval and active window. The available options are:
     • -5 America/Bogota
     • -4 America/Caracas
     • -3 America/Argentina/Buenos_Aires
     • -2 Atlantic/South_Georgia
     • -1 Atlantic/Cape_Verde
     • 0 UTC
     • +1 Europe/Madrid
     • +2 Europe/Helsinki
     • +3 Europe/Moscow
     • +4 Asia/Dubai
     • +5 Asia/Karachi
     • +6 Asia/Dhaka
     • +7 Asia/Bangkok
     • +8 Asia/Shanghai
     • +9 Asia/Tokyo
     • +10 Australia/Brisbane
     • +11 Pacific/Noumea
     • +12 Pacific/Tarawa
   • In the “Interval” section, use the “Run Every” field to set how frequently the flow will start. For example, when selecting 1 hour, the component will attempt to run the flow once every hour, provided it is within the authorized days and times. You can select:
     • 5 minutes
     • 10 minutes
     • 15 minutes
     • 30 minutes
     • 1 hour
     • 2 hours
     • 3 hours
     • 4 hours
     • 6 hours
     • 8 hours
     • 12 hours
     • 24 hours
   • In the “Active Window” section, use the buttons in the “Active Days” field to select one or more execution days. The selected days will be enabled for component execution:
     • S: Sunday.
     • M: Monday.
     • T: Tuesday.
     • W: Wednesday.
     • T: Thursday.
     • F: Friday.
     • S: Saturday.
   • Under “Active Schedule” (Although the interval indicates periodic execution, the Sentinel Component will only start the route when the current time is within this window.), configure the following fields:
     • Start Time: the time from which the flow is allowed to run.
     • End Time: the time until which the flow is allowed to run.

New Deep Research Component for autonomous analysis in wolkvox Studio

wolkvox Studio includes the new Deep Research Component, also known as Agentic Deep Research, an agentic artificial intelligence module designed to perform comprehensive searches, investigations, and analyses based on the instructions defined by the flow designer.

Unlike a conventional query, this component can interpret a complex objective, follow specific guidelines, evaluate the information collected, and consolidate the findings into a structured response. This makes it possible to add advanced research capabilities to a Routing Point without manually building multiple data retrieval, validation, and organization steps.

The generated result is automatically stored in the predefined $ResDeepR variable, from which it can be used by other flow components to continue the automation, make decisions, present information to the user, or execute new actions.

The component is available in the following Routing Point types:

• Voice Flow
• Chat Flow
• Interaction Flow
• Agentic Engine

The Deep Research Component is not available in Agent Scripting.

Benefits

• Autonomous contextual analysis: Performs extensive research based on detailed guidelines, interpreting the objective and applying the rules defined by the administrator.
• Reduced design complexity: Reduces the need to create multiple connections and conditions to retrieve, validate, organize, and consolidate information within the Routing Point.
• Business-specific guidelines: Makes it possible to define the AI’s role, the research objective, expected data, restrictions, accepted sources, and response format.
• Persistence across research runs: The Enable Session Memory option makes it possible to retain findings from previous executions to preserve context during consecutive research processes.
• Integration with other components: The result is stored in $ResDeepR, allowing it to be reused in text, TTS, condition, database, integration, autonomous agent, or other flow components.
• Validation before production: The Test Agent button makes it possible to review the component’s behavior and adjust the instructions before connecting it to the rest of the process.

What can the Deep Research Component be used for?

The component can support processes that require collecting, evaluating, and organizing information from different sources. Some examples include:

• Prospecting companies or potential customers based on commercial criteria.
• Researching markets, industries, competitors, or trends.
• Collecting public information about organizations and contacts.
• Comparing products, services, prices, or conditions.
• Preparing executive summaries for agents or internal teams.
• Analyzing background information before a sales, support, or collections interaction.
• Identifying opportunities and risks based on business-defined rules.
• Obtaining structured information to store in a CRM or database.
• Preparing context for another autonomous agent to continue the process.
• Validating whether the information found meets mandatory requirements before continuing through the flow.

For example, the designer can configure the component as a sales prospecting analyst and ask it to identify restaurants in a city, provide their contact details, explain why they could be potential customers, and include the exact source used.

How to configure the Deep Research Component

1. In the component sidebar, open the “Cognitive” tab and locate the “Agents” section.
2. Drag the component to the part of the flow where you need it.
3. Left-click the component to open the configuration panel on the right side.

In the “Name” tab, enter a clear identifier for the component. The name should make it easy to locate within the flow, especially when multiple agents or research processes are used. Some examples include:

• Restaurant prospecting.
• Customer research.
• Competitor analysis.
• Supplier validation.

Switch to the “Description” tab and enter additional information about the purpose of the component. This field can be used to document what it researches, where it runs within the process, or which result is expected.

In the “Research Guidelines” field, enter the general context that will guide the agent’s behavior. These instructions may include:

• The role it should assume.
• The general objective.
• The fields it must return.
• The mandatory rules.
• The accepted sources.
• The criteria for discarding results.
• The maximum number of records.
• The language and response format.

Example: 

# Role

You are a sales prospecting analyst specialized in identifying potential companies.

# Objective

Identify restaurants that could become customers for the distribution of natural beverages.

# Required fields

- Company
- City
- Phone
- Email
- Address
- Notes
- Source

# Rules

- Return a maximum of 20 results.
- Do not invent missing information.
- Prioritize official sources.
- Avoid duplicate records.
- Respond only in English.

The guidelines act as the permanent framework for the research and must be clear enough to define how the agent should reason and respond.

In the “Research Request” field, specify the exact task to be performed. For example:

Find sales opportunities among restaurants located in Medellín.

While the guidelines define the agent’s general behavior, the request specifies what it must research during that particular execution.

Click “Test Agent” to validate the configuration.

The system processes the entered guidelines and request and generates a local HTML file containing the test result. This file opens automatically in your default web browser once the test finishes loading. The path may have a structure similar to the following:

C:/ipdialbox/download/wolkvox_deepresearch_test_20260723_165400.html

In the file, you can review:

• The guidelines or prompt used.
• The research request.
• The generated result.
• The session memory status.
• The execution date and time.
• The identifier of the tested component.

This test makes it possible to verify whether the agent correctly interprets the rules, finds the expected information, and generates an appropriate output format.

Select the “Enable Session Memory” checkbox when consecutive research processes need to retain context and previous findings.

• Enabled: the component can use information obtained during previous executions in the same session.
• Disabled: each research process begins without considering previous results.

This option is useful for progressive research, refinements, or cycles in which each new request depends on previously discovered information.

The predefined variable is displayed under Research Result Variable:

$ResDeepR

This variable stores the complete response generated by the component.

The variable name is fixed and cannot be changed.

You can use $ResDeepR in subsequent flow components to:

• Display the result to the user.
• Convert it into audio using TTS.
• Evaluate it in a condition.
• Store it in a database.
• Send it to an external system.
• Provide it as context to another agent.
• Continue an automation based on the findings.

Click “Save” to apply the component configuration.

New Agentic DB Component for managing MySQL databases with AI in wolkvox Studio

wolkvox Studio includes the new Agentic DB Component, also known as Agentic Database or Agentic MySQL DB, an artificial intelligence module designed to interact directly with MySQL databases through natural-language instructions.

The component allows a flow to retrieve, insert, update, or delete information and, when authorized by the guidelines, perform more advanced actions such as creating tables. This allows the designer to automate data operations without building extensive SQL queries or developing an intermediary API for each action.

Its behavior is controlled from the configuration panel using guidelines that define what the agent should do, which information it can work with, and which restrictions apply. The specific request can be entered directly or received from a variable generated by another flow component.

The result of each execution is automatically stored in the predefined $ResDBAgentic variable so it can be used by subsequent Routing Point components.

Agentic DB is available in the following Routing Point types:

• Voice Flow
• Chat Flow
• Interaction Flow
• Agentic Engine

The component is not available in Agent Scripting.

Benefits

• Natural-language database operations: Makes it possible to perform actions on MySQL without manually writing complex SQL queries for each flow scenario.
• Dynamic automation: The agent can interpret the received context and determine the required operation according to the configured guidelines, such as retrieving a record, inserting information, or updating existing data.
• Direct integration with flows: The component can receive information generated during a call, chat, interaction, or autonomous process and use it to perform actions in the database.
• Control through guidelines: The administrator can restrict the agent’s behavior by defining the permitted tables, fields, operations, and rules. This helps prevent actions that do not correspond to the defined objective.
• Result persistence: The response or confirmation generated by the component is stored in $ResDBAgentic, making it easier to use in conditions, messages, subsequent queries, or external integrations.
• Validation before implementation: The Test Agent option makes it possible to run a test and review the connection data used, prompt, submitted request, and result in an HTML file.

What can Agentic DB be used for?

The component can be incorporated into processes that need to automatically retrieve or modify information. Some examples include:

• Checking the status of a request, order, account, or service.
• Searching for customer information using an identification document or phone number.
• Registering leads obtained during a conversation.
• Inserting results generated by a research component.
• Updating customer contact details or preferences.
• Changing the status of a case, ticket, or interaction.
• Creating audit or tracking records.
• Validating whether a customer meets specific conditions.
• Retrieving inventory, balances, availability, or history.
• Deleting or cleaning up records when authorized by the process rules.
• Creating tables or structures required for a controlled process.
• Providing database information to another Routing Point component.

For example, a flow can first run the Deep Research Component, store its findings in $ResDeepR, and then send that variable to Agentic DB to structure and insert the information into a MySQL table.

Component configuration

1. In the sidebar, select the “Cognitive” tab. In the Agents section, locate the Agentic DB Component.
2. Drag it onto the design canvas.
3. Double-click the component with the left mouse button to open its configuration panel on the right side.

In the “Name” tab, enter an identifier that makes it easy to recognize the component’s function within the flow.

Some examples include:

• Retrieve customer.
• Register prospect.
• Update request status.
• Save research result.
• Validate balance.

Select the “Description” tab and enter additional information about the component’s objective.

You can indicate which database it uses, which operation it performs, or at which point in the flow it should be activated.

Complete the connection fields:

• DB User: name of the user authorized to access the database.
• DB Password: password corresponding to the configured user.
• Server IP: IP address of the server where the MySQL database is hosted.
• Database Name: exact name of the database on which the agent will operate.

Verify that the information is correct before testing the component.

In the “Agentic DB Guidelines” field, enter the general context, objective, and rules that the agent must follow when working with the database.

The guidelines may specify:

• The role the agent must assume.
• The table on which it can operate.
• The fields it can retrieve or modify.
• The expected data format.
• The permitted operations.
• The actions it must not perform.
• How missing data should be handled.
• The conditions required to insert or update information.

Example:

# Role and objective

You are an agent specialized in data extraction and database management.

You must analyze the received information, identify the prospect’s data, and insert it into the `prospects` table.

# Fields

- company
- city
- phone
- email
- address
- notes
- source

# Rules

- Do not invent information.
- When data is unavailable, use `null`.
- Do not delete records.
- Do not modify tables other than `prospects`.
- Before inserting data, verify that the record is not duplicated.

The guidelines must clearly define the agent’s scope. The component will use these instructions as a reference when interpreting each request.

In “DB Request,” enter the specific task the agent must perform.

The request can contain direct text:

Retrieve the customer with document number 123456789 and return their name, status, and balance.

It can also use a flow variable:

$ResDeepR

In this case, Agentic DB receives the content stored in the variable and processes it according to the configured guidelines. This makes it possible to connect the component to Deep Research results, customer messages, forms, previous queries, or other components.

Click “Test Agent” to validate the configuration before incorporating it into the production flow.

The system generates a local HTML file at a path similar to:

C:/ipdialbox/download/wolkvox_agentic_mysql_test_20260724_132420.html

The test report includes information such as:

• Generation date and time.
• Component identifier.
• Session memory status.
• Configured server or host.
• Database user.
• Database name.
• Guidelines sent to the agent.
• Processed request.
• Execution result.

The Result field makes it possible to verify whether the operation was completed successfully or determine why it could not be completed. For example, it may indicate that mandatory information was missing, that the request did not contain enough information, or that the requested operation could not be performed in the database.

Select the “Enable Session Memory” checkbox when the component needs to retain the context of previous executions during the same session.

• Enabled: the agent can consider previous requests and results.
• Disabled: each execution is processed independently.

This option can be used in consecutive processes, such as first retrieving a record and then updating it using the context already obtained.

The predefined variable is displayed under Agentic DB Result Variable:

$ResDBAgentic

The name of this variable is fixed and cannot be changed.

It stores the response generated by Agentic DB, which may include:

• The records found.
• Confirmation of an insertion.
• The result of an update.
• The number of affected records.
• A validation message.
• An explanation of an error or an operation that was not performed.

Subsequently, $ResDBAgentic can be used to display a response to the customer, evaluate a condition, provide information to another agent, save an additional record, or continue the automation.

Click “Save” to apply the changes.