Luware Knowledge

Nimbus Portal Nimbus Admin Nimbus Release Notes Luware Cloud Status
Home Luware Nimbus Usage of Nimbus Configuration Workflows Workflow Activities Conversation Handling Activities

Add Virtual User

Add Virtual User

Description

Adds a preconfigured Virtual User (AI Bot) to engage with the Customer. 

✅ Preconditions for this activity must be met. Refer to the Virtual User page for more details. You may also read Use Case - Integrating Nimbus Virtual User with external systems for a step-by-step example.

✅ Licensing: Missing “Virtual User” licenses will affect productive workflows: During an incoming call – and with no license applied to a Virtual User in your workflow – the “Failed” exit is taken automatically. The exit is also taken on any technical errors or service outages.
→  To handle this case, a fallback Queue / Transfer or Announcement activity is recommended after the “Failed” exit.

 
Required Predecessor Accept
License
Advanced Routing Enterprise Routing Contact Center
Modalities Audio / Video Instant Messaging Email External Task

Common Properties

Configurable Properties Description
Virtual User

✅Virtual User preconditions and License must be applied for your Virtual User to be able to process customer inputs.

💡The Virtual User pulldown directly affects the behavior and configurable properties within the Virtual User activity. 

Virtual User activity properties with bot profile “Copilot Direct Line” selected. Exit outputs are mapped  and evaluated using Regular Expressions (Regex).

 
Virtual User activity properties with either bot profile “AI Workflow, Intent Analyzer, Open Profile” selected. This example has one “success” exit mapped, which is retrieved from the chosen Virtual User configuration.
Table: Example Virtual User Activities with various properties, based on the selected “Virtual User” configuration

🔎Notes

 
Max Input Timeout               
hh:mm:ss (default 00:01:00)

✅ Applies for the “Copilot” Virtual User Bot profile.

Maximum wait time for any Customer Response

  • Min: 00:00:05
  • Max 00:10:00

💡 If no interaction occurred between Customer and Bot, the "Idle Timeout" exit node is used. 
Fallback Parameter

✅ Applies for the Virtual User Bot profiles: Intent Analyzer, AI Workflow, Open Profile

Used to store a fallback response by the Virtual User into the specified Parameter. 

🔎 Purpose: If no other exit could be determined during the conversation, the Virtual User will store any identified “unhandled” outcome into this parameter. Note this reply can vary in length, so below is just an example:

Repeated errors occurred while validating the Policy ID number '1234. Unable to proceed with the request to verify the Customer Policy.

💡Usage as context: While it is possible to display this parameter in the Nimbus UI (e.g. as Extensions Service Settings > My Sessions), this data is more meant for further processing. Examples could be evaluation of the parameter in automated Flows, transfers to fallback services, or for storage of customer requests that cannot be covered by the AI (and underlying Bot).

 
Text to Speech

✅ Applies for the “Copilot” Virtual User Bot profile.

Uses Microsoft Text-to-Speech routines to convert the bot response into audio for the Customer.

💡Note that the configuration of your Virtual User (e.g. “Topics” within Copilot Studio) determine how long these audio replies can get. We advise to give the bot instructions to limit itself to a maximum of 2-3 sentences.
Common Default Exits

✅ Applies for all Virtual User types. 

  • Failed - Taken when: 
    • … the activity is disabled,
    • … no Virtual User license is applied in the configuration.
    • … connections to external tools, e.g. via Web Requests or MCP server connections have failed.
    • … other technical issues occurred, e.g. the connection to the bot itself failed, or other error response codes.
  • Idle Timeout …
    • … for Copilot: Taken if no interaction with the Customer occurred until Max Input Timeout is reached.
    • … for GPT Realtime: You can define the timeout behavior in the Virtual Users > Behavior tab.
Custom Exits 

☝️Note: Regardless of model chosen, custom exits / outcomes should be written in one word (without space characters) - e.g. "invoice_number" and avoid special characters in general - otherwise they may not be correctly detected by the corresponding AI Model.

 

✅ Custom exits behave based on the Bot configuration (AI-model) chosen within selected Virtual User. These are follows: 

For Nimbus (AI Workflow, Intent Analyzer Open Profile)

☝️By default there is no “Success” exit in this activity. Exits are defined as “Outcomes”, within the Virtual User itself.

✅In the “Add Virtual User” activity, you map these outcomes as exits:

  1. ⮑ Outcomes marked with "This outcome triggers an exit” in the Virtual Users > Outcomes list will appear in this selection list. On this activity you simply …
  2. … select the exit outcome(s) you want to handle.
    ⮑This will add the exit as a node to the activity. 
  3. Finally map each exit to follow-up activities. 
…further outcomes can be added as dynamic exits, as defined on the Virtual User

🔎 Notes

☝️While still mapped within a workflow, an existing exit outcome cannot be deleted on the Virtual User config.

💡Each outcome can store and update up to 10 Parameters each. The AI will determine which customer data to fill into these parameters, based on the “Virtual User Instructions” specified in the Parameters config, and the tools / information available to the bot at the point of the call.

💡Whenever a customer request cannot be handled, the AI will use the “AI Fallback” exit.

 
 
 

For Copilot

☝️By default there is no “Success” exit in this activity. Exits are evaluated based on regular expressions. For Copilot as AI model, successful exits are determined by the bot's responses (e.g. gathered in Copilot itself via the use of conversation topics). In Nimbus, the bot response is then mapped data fields using Bot Response Templates, which are then specified in your Virtual User for evaluation via regular expressions.

✅In the activity, you evaluate exits as follows:

  1. First, define a name for your exit, then…
  2. …a Regex condition - taken if a Custom field from the Bot Response Templates matched with the Regular Expressions in your workflow exit. 

🔎 Notes

☝️Keep in mind that the first (leftmost) exit with successfully matching regex pattern applies. Ensure that there are no overlaps or ambiguity between existing exits in your regex syntax.

💡The Workflow exit name is purely for your identification. Only the regex pattern and exit matters in the configuration.

 
 
 

☝️Note: The Outcomes dropdown is limited to a maximum of 12 connections: 2 default connections (Fallback and Failed) plus up to 10 configurable outcomes.
💡This limit applies only to the workflow activity (Admin Portal > Configuration > Workflow Manager > Virtual User Activity) — it does not restrict how many outcomes can be configured on the Virtual User itself. The cap keeps outcome mapping manageable on the workflow canvas and improves the Virtual User's ability to reliably identify the right outcome when too many exits are configured.
 
 

Audio / Video

 
 
Best Practices - Virtual Users in Nimbus

The challenge when building Virtual Users in Nimbus isn't just about building...

INC AI and Virtual User Limitations

General note on AI-driven interactions AI driven replies are very dependent on wh...

Table of Contents