Documentation in progress. New content is added regularly.

Helvia.ai Release 2026.06.04

04 June 2026

1. Enhance Startup Notifications with Images

You can now add images to WebChat startup notifications, making it easier to promote campaigns, announcements, and important updates directly within the chat experience. Images can be displayed alongside notification text, creating a more engaging and visually impactful first impression for users.

Why it matters: Previously, startup notifications were limited to text-only messages, reducing their visibility and promotional potential. With image support, you can draw attention to key announcements, seasonal campaigns, product launches, or special offers while maintaining a seamless user experience.

Example use case: A retailer displays a promotional banner for a seasonal sale when users open the chat widget. Clicking the banner opens the campaign landing page in a new tab, while the notification text provides additional context and call-to-action details.

How it works: When configuring startup notifications in your deployment settings, you can now optionally add a single image using an external URL. Notification text remains required, ensuring content is still displayed if the image cannot be loaded. You can also configure an optional link that opens in a new browser tab when users click the image. Existing startup notifications continue to work without any changes.

2. Add Friendly Names to Semantic Search Nodes

You can now assign a Friendly Name to Semantic Search nodes, making it easier to identify and distinguish search steps within complex agent workflows. This brings Semantic Search in line with other action nodes such as HTTP Request and LLM, which already support custom labels.

Why it matters: Previously, multiple Semantic Search nodes could only be differentiated by the variable they stored results in, making flows harder to understand and debug. With Friendly Names, builders can clearly label the purpose of each search step, improving readability and observability across both the Designer and interaction logs.

Example use case: An AI agent contains separate Semantic Search nodes for Product Documentation, Internal Policies, and FAQ Content. By assigning a Friendly Name to each node, builders can instantly identify which knowledge source was queried when reviewing the flow or troubleshooting execution logs.

How it works: A new optional Friendly Name field is available in the Semantic Search node configuration. When provided, the name is displayed on the node card in the Designer and is included in interaction logs and session traces. If no Friendly Name is set, the platform automatically falls back to the configured variable name, preserving existing behavior and ensuring full backward compatibility with previously created flows.

3. Export Audit Logs to CSV

Workspace Administrators can now export audit logs to CSV, making it easier to support compliance reviews, security investigations, and long-term record keeping. Exports automatically include all records matching the currently applied filters, ensuring the downloaded data reflects exactly what you are viewing.

Why it matters: Previously, audit logs could only be reviewed within the platform, making it difficult to share records with auditors, retain evidence outside the configured retention period, or perform offline analysis. With CSV export, administrators can easily archive and distribute audit data when needed.

Example use case: During a compliance audit, an administrator filters audit logs to a specific date range and activity type, then exports the results to share with internal stakeholders or external auditors as supporting evidence.

How it works: From the Audit Logs page, apply the desired filters and select Download. The platform generates a CSV file containing all matching records. The exported file includes key audit information such as timestamps, actors, actions, categories, affected objects, and descriptions, providing a complete audit trail for the selected criteria.

4. Export Session Data Without Conversation Messages

You can now choose to exclude conversation messages when exporting session data from the Observatory. This allows you to generate exports containing only session-level information, significantly reducing export size and improving performance for large datasets.

Why it matters: Previously, session exports always included the full conversation transcript, resulting in larger files and longer processing times. With the new option to exclude messages, administrators can quickly export session metadata for reporting, analytics, or operational reviews without waiting for transcript-heavy exports to complete.

Example use case: An operations manager needs a monthly export of session activity, feedback scores, and engagement metrics for reporting purposes. By excluding conversation messages, the export is generated much faster while still containing all the information required for analysis.

How it works: When exporting sessions from Observatory → Sessions, you can enable the Exclude Messages option before downloading the file. The export will then contain one row per session with session-level data only, omitting all transcript content. Existing filters continue to apply, ensuring the exported data matches the selected criteria. If the option is not enabled, exports behave exactly as before and include the full conversation history.

5. Bookmark-Friendly Date Range Presets in Observatory

Date range presets in the Observatory now stay relative to the current date when saved or shared. This means bookmarks and shared links using presets such as Last 7 Days, Last 30 Days, or Last Month will always display the most recent data instead of a fixed historical period.

Why it matters: Previously, preset date ranges were stored as absolute dates. A bookmarked "Last 7 Days" view would continue showing the same week indefinitely, leading to outdated reports and confusion when sharing links. With this update, preset-based views remain current every time they are opened.

Example use case: A team lead bookmarks an Observatory dashboard filtered to Last 30 Days and reviews it each week. The dashboard automatically updates to reflect the latest 30-day period without requiring manual date adjustments.

How it works: When you select one of the predefined date range presets, the platform now stores a relative time range behind the scenes. Each time the page is loaded, the range is recalculated against the current date and time. Custom date ranges continue to behave as before and remain fixed to the exact dates selected. Existing bookmarked URLs remain fully supported.

6. Track Redirect Executions in Interaction Logs

Redirect actions are now recorded in the Observatory interaction logs, giving you greater visibility into how conversations move through your agent workflows. Both successful redirects and redirect errors are captured, making it easier to trace execution paths and diagnose configuration issues.

Why it matters: Previously, Redirect nodes executed silently and any configuration errors—such as redirecting to a non-existent flow—were only visible in technical logs. This made troubleshooting difficult and often required engineering support. With this update, redirect activity is now visible directly in the session trace, providing a more complete view of agent behavior.

Example use case: An AI Agent Engineer is investigating why a conversation unexpectedly stopped. By reviewing the interaction logs, they can see exactly which Redirect node was executed and whether it successfully routed the user to the intended flow or failed due to a missing target.

How it works: Every time a Redirect node is executed, a new Redirect event is added to the interaction logs. If the target flow exists, the event is recorded as successful. If the target cannot be found, the event is logged as an error, allowing administrators and bot builders to identify and resolve routing issues directly from the Observatory.

7. Create Dynamic Routing with Variables in Redirect Nodes

Redirect nodes can now use variables and templates to determine the destination flow at runtime, enabling more flexible and scalable conversation routing. This allows AI agents and orchestrator flows to dynamically decide where a conversation should continue without relying on large chains of conditional logic.

Why it matters: Previously, each possible routing path required a separate Redirect node and supporting conditions. As workflows grew, routing logic became increasingly difficult to maintain. With dynamic redirects, a single Redirect node can route users to different flows based on variables generated during the conversation.

Example use case: An AI-powered orchestrator determines whether a user should be handled by a sales, support, or billing workflow. Instead of creating multiple conditional branches, the agent stores the selected destination in a variable and redirects the conversation dynamically to the appropriate flow.

How it works: In the Redirect node, the Flow to redirect to field now supports variable templates using the same syntax available throughout the platform, such as { { agentId } } or flow_{ {language} }_{ {department} }. At runtime, the platform resolves the value and redirects the conversation to the matching flow. If the target cannot be resolved or does not exist, the error is automatically recorded in the interaction logs, helping builders quickly identify routing issues.

Last updated

Was this helpful?