Luware Knowledge

Nimbus Portal Nimbus Admin Nimbus Release Notes Luware Cloud Status
Home Luware Nimbus Administration Configuration (Admin) AI

Virtual Users

Leverage AI-driven bots to use within your workflows

A Virtual User is an AI-powered assistant that interacts directly with calling customers - greeting them, providing retrieved information, capturing context to store in parameters and handing the conversation result back to Nimbus Workflows for further routing.

PRECONDITIONS: AI Features, Bots and Virtual Users

✅ Nimbus Tenant Admin consent is required to enable the use of AI features. This is done in the Data Privacy Tenant Settings.  AI use will require your Tenant data (e.g. caller information) to be processed by external services.

💡Note that disabling AI features later resets related AI Service Settings; see Data Privacy Tenant Settings for details.

💡Good to know - shared setup effort: Once consent is granted, both Admin Roles “Tenant Admins” and “OU Admins” are able to create various AI Configuration items in the Nimbus Admin Portal. This also includes:

  • Access to Service Distribution Settings, e.g. to test workflows with your configured Virtual Users. 
  • Steer feature visibility via AI Service Settings (e.g. when activities are supposed to happen unobtrusive in the background).
 
 

Virtual User Licensing

✅Nimbus License Management: 

  • Contact Center Enterprise Routing service licenses are required to use AI-driven Virtual User functionality. 
    ⮑With the license applied, corresponding Service Features (e.g. workflow activities, configuration tabs) are enabled.
  • Individual Virtual User license requirement: Same as regular Nimbus users, each Virtual User requires a separate license. This license can be applied individually in the Virtual User configuration - or in bulk - via Admin > Licensing view. 
    ⮑The license enables usage of the “Add Virtual User” Workflow Activity, without it the activity will be skipped over. For additional Virtual User licenses on your service, get in touch with your Customer Success representative.
 
 

Virtual User Bot Configuration

Virtual Users rely on Nimbus Configuration items:

✅ ALL: Virtual Users require Bots to be configured. Your bot choice also determines the underlying AI LLM into which the Nimbus Virtual User integrates. Your bot type and profile should therefore be chosen with the intended use case in mind.

Defined in Bots Defined in Virtual Users 

Type

Nimbus managed or BYO

AI Service

Underlying LLM

Virtual User Profile

Pre-built configurations to fulfill a certain use case
Nimbus AI Services Azure OpenAI GPT Realtime1
  • Intent Analyzer  - Intent Analysis Use Cases. 
  • AI Workflow - Extending Virtual User with additional external system capabilities (MCP and/or Web Request, both optional) and route the conversation outcome back into Nimbus Workflows 

Custom AI Services

 
  • Intent Analyzer  - Intent Analysis Use Cases. 
  • AI Workflow - Extending Virtual User with additional external system capabilities (MCP and/or Web Request, both optional) and route the conversation outcome back into Nimbus Workflows 
  • Open Profile - Same as AI Workflow, but with additional controls over Verbosity, Tone, Role 
M365 Copilot Direct Line 3.0

Notes

1 Due to Microsoft Azure AI foundry availability in limited regions, data processed by a Nimbus Virtual User “GPT”-Realtime" integration might temporality leave a cluster due to failover scenarios:

  • Nimbus Cluster DE01, DE02, CH01, CH02, UK01, EU01, AU01 computation will be primarily performed in Sweden Central region.
  • Nimbus Cluster US01 computation will be primarily performed in the US East region.
 

✅SPECIFIC AI services / Agent technologies (e.g. Microsoft Copilot) may require additional configuration items such as: 

🔎For more details and specific configuration steps, refer to our AI Use Cases category and the specific Use Cases and pages linked above.

 
 
 

Use Cases

Virtual Users enable responsive, scalable self-service bots that can detect caller intent and integrate with external systems before — or instead of — handing over to a human agent. The list below showcases a few examples. 

Call triage Captures the callers intent and routes to its downstream flow. Set up with Virtual User Outcomes: such as "Create ticket", "Check status", “Escalate”
Identification gate Outcomes: Identified, Not Verified, Fraud Suspected — personalized self-service vs. manual verification vs. priority security queue.
FAQ with escalation Outcomes: Answer Found, Low Confidence, User Requests Agent — answer in-bot, offer alternative handling, or hand straight to an agent.
Payment / transaction Outcomes: Successful, Failed, User Aborted — confirmation, retry, or graceful exit.
Password reset Outcomes: Reset Successful, Reset Failed, User Locked Out — confirmation, retry, or escalation to support desk.
Survey Outcomes: Completed, Partial Completion, Drop Off — thank-you message, follow-up, or callback workflow.
Card blocking Outcomes: Card Blocked, Identification Failed, User Cancelled — confirmation with audit log, high-priority escalation, or safe exit.

Optional Features

Transcription Optionally, all Virtual User actions can have Transcription features enabled. This allows to extract the spoken transcript via Power Automate Connector for further storage, quality assurance or case evaluation purposes.
Summarization Once a session has ended, Virtual User can also generate a short Summarization. It contains the customer request, what the Virtual User did in response, and how the session concluded. Finished summaries are retrieved via Power Automate Connector, e.g. to open a CRM case, hand context to a human agent, or feed a QA workflow.

Configuration

💡Good to know: in Companion - Virtual User Configuration Assistant

✅ Optional Feature for Administrators: Instead of configuring a Virtual User manually – as described below – administrators can let Nimbus Companion Chat Interface guide them through the setup. Companion proposes a structured configuration (Profile, General Instructions, Outcomes & Tools Instructions, outcomes and parameters, and suggested tools). After your confirmation, Companion can create or update the bot and the Virtual User for you.

Learn more…

Nimbus Companion can guide administrators through configuring Virtual Users in a conversation. Based on the intended business use case, Companion proposes a structured configuration and can create or update the Virtual User for you. This reduces setup effort and improves the quality of your prompts from the first attempt.

✅Preconditions

  • This configuration feature is exclusive to Nimbus Admin Portal, as only Admin users create or update Virtual Users.
  • Companion-assisted configuration is available for "Nimbus AI Services" Bots. Companion suggests either the Intent Analyzer or the AI Workflow profile, depending on your use case.
 

💡Good to know:

  • Tools are limited to Web Requests. MCP tools aren't supported yet, and the Web Requests configuration entities must already exist for reference. Companion doesn't handle endpoints or secrets.
  • New Virtual Users are created in the language you use when talking to Companion. You can tell Companion if you want a different one. 
  • If no license is available, you can still save the Virtual User to apply the license at a later point.
 

Starting a configuration

Describe your business use case in the chat, or ask Companion to help you create a Virtual User. Companion distinguishes between general questions and concrete configuration requests, and uses the Knowledge Assistant or the Virtual User Configuration Assistant accordingly:

  • General questions (e.g. how to configure a Virtual User): Companion answers as Knowledge Assistant, giving a concise overview based on the information in the Knowledge Base, and offers to help you configure a Virtual User in your tenant.
  • Concrete requests (e.g. “Help me create a Virtual User for call triage”): Companion switches to the Virtual User Configuration Assistant and starts the guided configuration.

Guided configuration

  1. Create or update: Companion identifies whether you want to create a new Virtual User or update an existing one.
  2. Use case questions: Companion asks about the key tasks of the Virtual User, the expected outcomes, and the required parameters and data inputs. If information is missing or unclear, Companion suggests best-practice defaults and examples. Opening and final messages are suggested by Companion, unless you specify them yourself.
  3. Bot type and profile: Depending on your use case, Companion suggests either the Intent Analyzer or the AI Workflow profile. For the AI Workflow profile, Companion also suggests tools.
  4. Configuration proposal: Companion generates a structured proposal with the Virtual User profile, General Instructions, suggested tools with Outcomes & Tools Instructions, and the defined outcomes and parameters.
  5. Name and organization unit: Enter a name and select the organization unit from a form, without pasting object IDs.
  6. Confirmation: Companion asks for your confirmation before it creates or updates any Virtual User.

Improving existing Virtual Users

Companion can also help with Virtual Users you already have. It can refine their prompts, identify missing elements such as intents, parameters, or opening and final messages, and propose additions. It can also suggest a consistent conversation style and configuration structure across several Virtual Users, including adjustments for each one.

💡Good to know

  • License: Companion allows you to assign a license. If no license is available, you can still save the Virtual User. Companion notifies you about the missing license.
  • Defaults: New Virtual Users are created in the language you use when talking to Companion (for example German, if you write in German). If you want a different language, tell Companion which one to use. If you mention a specific voice, Companion uses it.
  • More details: For all settings of a Virtual User, see the Virtual Users page.
 
 
 
 

General

General

Nimbus-related general settings for the Virtual User.

Field Description
Name The name of the Virtual User, as it will appear in other selection dialogues of Nimbus (e.g. within Workflows).
Organization Unit Determines where the Bot will be available for selection.
Description

A Nimbus-internal description, e.g. “Support Bot for first response IVR”.

💡This field is optional, just for identification within the Nimbus UI and will have no impact on the Bot behavior.

💡Limited to 256 characters. If you previously saved a longer description, the UI indicates the overflow.

Bot Configuration

✅Dependent on the “Organization Unit” selected: Provides a selection of previously configured Bots (AI models) and related configuration profiles. Based on the Bot and profile choice, other tabs and options become available.

💡If the bot you need doesn’t exist yet, the + Create button next to Bot Configuration in the form opens the Bots page, where you can create it.

Property Description Notes
Bot

✅Pick a previously configured Bot.

⮑ The Bot's underlying model determines which options become available in the following.

 🔎More details in the Preconditions above.
Profile

Various configuration profiles that steer the AI behavior. Choices are:

  • Intent Analyzer - Simple intent analysis and routing in Workflows
  • AI Workflow - Additional MCP and Web Request capabilities
  • Open Profile - Same as AI Workflow, but with additional prompt flexibility and controls over Verbosity, Tone.

⮑ The choice automatically changes the visible properties on the tabs described further below.

 ✅ Required except for “Copilot Direct Line 3.0”

Bot Response Template 

 

 Bot Response Templates map the JSON response your Bots (external APIs) deliver, with the goal to use that response as criteria within your Workflows.  ✅Required when “Copilot Direct Line 3.0” was selected as a Bot. 

Modalities

Property Description Notes
Modalities

Enables the bot to handle and react to Audio/Video (calls).

⮑ Depending on Bot selection, an additional Speech Recognizer may be required → See below.

 💡Currently the choice is locked. Further modalities will be made available in future.
Speech Recognizer

Speech Recognizers (used for speech-to-text transcription) to be configured for selection in this menu.

💡 Speech Recognizers are used to parse the language of the calling customer into text for the bot to process. They can be configured as multilingual-capable, but are more effective when set to a specific language.

 ✅Required when “Copilot Direct Line 3.0” was selected as a Bot.

Licenses

Property Description Notes
Licenses

⮑ This actively draws from your License Management pool and allows services to effectively use your “Virtual User” in production.

 

 💡If you require additional Virtual User licenses, get in touch with Luware Customer Success.
 
 

Behavior

Behavior

✅ This tab and contents are shown depending on General > Bot Configuration. It steers general instructions for the Virtual User, e.g. the instructions sent to the AI model. It also defines the Messages, Voice & Language and Persona settings.

Property Description Notes
General Instructions

The main free-text prompt. 

  • Steers the Virtual User behavior and goals.  
  • Defines the bot's persona, domain knowledge and rules.

10,000 chars limit

Supports Custom Parameters and System Parameters 

Messages

Property Description Notes
Initial Message to Customer

Not an instruction or prompt, literal message of the first thing the caller hears when the Virtual User joins the workflow. 

☝️ Taken Literally: The message is spoken exactly as written, in the language or languages it is written in. It is not translated into the language set under → “Voice & Language”.

💡To greet callers in several languages, write the message in each of them, e.g. "How can I help you? Wie kann ich Ihnen helfen?". 
💡 Callers can answer and continue in the in the language they prefer.

🔎 When the Virtual User is invoked in Outbound Calls with Workflow, this is the message played when the called party picks up.

500 chars limit

Supports Custom Parameters and System Parameters 
Final Message to Customer

Final line the bot says before the activity exits. 

💡Useful for handing the caller over politely ("Connecting you now…") or closing the loop on a self-service interaction. 

💡May get dynamically translated when the conversation language got swapped mid-call. This also applies when the caller picks a language in response to a multilingual Initial Message to Customer.

500 chars limit

Supports Custom Parameters and System Parameters 

Timeouts

Specifies a maximum session duration 

Property Description Notes
Max Session Duration 
(seconds)

Maximum total duration the Virtual User stays in the call.

💡Example: After 6 minutes, the Virtual User will announce in the call that "the session timed out" and takes the "idle timeout" workflow exit.

Max duration depends on the Bot profile:

  • Intent Analyzer: 180s
  • AI Workflow:  1800s
  • Open Profile: 1800s
Inactivity Timeout 
(seconds)

How long the bot waits for caller input before taking the Idle Timeout exit of the “Virtual User” activity within the Workflow is taken.

💡Examples: 

  • Timeout: If the customer doesn't reply within in 45 seconds, the bot announces that “the session timed out” and takes the "idle timeout" workflow exit.
  • ☝️ Silence Prompt: If the caller stays silent, the Virtual User re-engages after 10 seconds (e.g. by asking whether the caller is still there) and once more after a further 10 seconds. 
    If there is still no reply, the Idle Timeout exit is taken once the configured Inactivity Timeout has elapsed. Both inactivity re-engagement attempts count toward the Inactivity Timeout. The 10-second interval is fixed and cannot be configured. 
  • While a tool call is still running, the Virtual User does not re-engage.

Max timeout depends on the Bot profile:

  • Intent Analyzer: 45s
  • AI Workflow:  45s
  • Open Profile: 45s

Voice & Language

Property Description Notes
Language / Voice

Optional spoken-language. 

💡Not available for Copilot Bots, which are configured via Speech Recognizers instead.

 ✅Only visible on bot profile: “AI Workflow” or “Intent Analyzer”
Virtual User Voice

Voice selection for the chosen language.

💡Not available for Copilot Bots, which are configured via Speech Recognizers instead.

Persona

Property Description Notes
Verbosity

Short label describing how chatty the bot should be:

  • Concise 
  • Balanced 
  • Detailed

💡Combined with Tone to color the bot's style.

 ✅Only visible on bot profile: “Open Profile”
Tone

Short label describing the desired conversational tone (e.g. "Friendly and professional", "Concise and factual").

💡Combined with Verbosity to color the bot's style.

Role 

(deprecated1)

Short label describing the persona the bot plays (e.g. "Customer service representative", "Pharmacy advisor"). 
💡Used as a building block of the system prompt.

1 Deprecation Note: The Role field will be phased out soon, to be merged with the Behavior > “General Instructions” in a future release.

 
 
 

Outcomes & Tools

Outcomes & Tools

✅ This tab and contents are shown depending on General > Bot Configuration. It steers how the AI interacts with external systems and how to orchestrate the tool flow when interacting with the customer. 

Property Description
Outcomes & Tools Instructions

A single free-text field on the Virtual User that tells the model…

  • … how to drive the conversation when Extension Tools (both MCP or Web Request) are involved. It is the bot's "playbook" — the model reads it alongside the System Instruction every turn and uses it to decide when to call a tool, which tool to pick, and what to do with the result.
  • … how to use the “Outcomes:” in a conversation (which can be used to retrieve information for the customer, fill Parameters and (optionally) follow exit the “Virtual User” Conversation Handling Activity.

💡Tips on writing Outcomes & Tools Instructions

  • Keep it concrete and step-driven. The model performs best when it can read the description as a numbered playbook rather than as prose:
  • Spell out the conversation phases (greet → identify → look up → confirm → close).
  • Name each tool by the exact label it has on the Virtual User — "call the OrderLookup Web Request", not "call the order system".
  • The order of execution (e.g. FIRST validate bank name, IBAN, THEN retrieve user name, ONLY THEN answer the inquiry)
  • Mandatory and optional steps with clear signal words (e.g. these steps must be successful | this step can be optional)
  • Handle errors, outlining what to do if the tool fails or returns nothing.
  • Avoid duplicating the General Instructions (role, tone, language). The Outcomes & Tools Instructions field is about  the technical information flow, not personality.

☝️Note: The following examples are mere reference points, not functionally verified with specific use case scenarios or products.

Example 1 — Web-Request-only (order status bot)

1. Greet the caller and ask for their order number.
2. Call the OrderLookup Web Request with the order number the caller provided.
3. If OrderLookup returns a result, read back the order status (shipped / processing / cancelled)
 and the expected delivery date.
4. If OrderLookup returns no result or an error, apologise, offer to transfer to a human agent,
 and end the conversation.
5. After confirming the status, ask whether there is anything else. If not, say goodbye and close.

Never invent an order status. Only state what OrderLookup returns.
 
 

Example 2 — MCP-Server-only (internal Jira helper)

1. Greet the caller and ask which Jira ticket they are calling about.
2. Use the JiraServer MCP Server to look up the ticket by ID.
 - Prefer read-only tools first (get-issue, search-issues).
 - Only use write tools (add-comment, transition-issue) if the caller explicitly asks for it
 and confirms with "yes" before you make the change.
3. Summarise the ticket: title, status, assignee, last update.
4. If the caller asks for a change, perform it through the JiraServer, then read back what changed.
5. Close by confirming what was done and offering to do anything else with the same ticket.
 
 

Example 3 — Mixed Web Requests + MCP Servers (concierge bot)

You handle two kinds of requests: account questions and ticket questions.

Account questions:
 - Use the CustomerLookup Web Request to identify the caller by phone number.
 - If CustomerLookup returns no match, ask the caller for their customer ID and try again.

Ticket questions:
 - Use the JiraServer MCP Server for everything related to support tickets.
 - Always look up the ticket first; never quote a status from memory.

General rules:
 - Never expose internal IDs, URLs or raw tool output to the caller.
 - If a tool fails twice in a row, apologise and offer to transfer to a human agent.
 - Keep answers under three sentences unless the caller asks for detail.
 
 
 

Outcomes

Outcomes represent the customer intentions the Virtual User can detect during a conversation. Instead of relying on a single Success conversation outcome, you define multiple, outcome-driven results and decide how each one continues in the Workflow.

Outcome VS Non-Exit intent comparison during a “Virtual User” workflow interaction. Each allows to update parameters.

✅Preconditions 

🔎"Outcome" feature availability: Outcomes are available using either “Nimbus AI Services” or "Custom AI Services", for the following Bots: Intent Analyzer, AI Workflow and Open Profile, 

  • ☝️Migration: Previous “Virtual User” activities: Previous Virtual User workflow activities had AI exits created on the workflow level (Audio Intent Analyzer) or hard-wired "Success" exits (AI Workflow, Open Profile) in the element. With the introduction of flexible Outcomes, manual migration is necessary to avoid any disruptions and configuration errors.
    • Simply replace the “Add Virtual User” activity with a new one to leverage flexible Outcomes:.
    • Define at least one exit Outcome on the Virtual User configuration page, and map the exit on the workflow level. With no exit configured, the workflow will take the “AI Fallback”.
  • 💡No migration required for Copilot bots: Copilot uses its own exit handling1. Copilot "Topics”, of which the outputs are then mapped into Bot Response Templates. 

1 Depending on selected bot mode, the “Add Virtual User" Conversation Handling Activity is changing available configuration and exit properties.

 
Property Description
Outcome Name

Mandatory, unique name for the outcome — this is the label you later select on the “Add Virtual User” activity when mapping it to a Workflow exit.

💡Keep it to one word and avoid special characters (e.g. create_ticket) so the AI model detects it reliably.
Instructions Mandatory free-text that tells the Virtual User when to assign this outcome (e.g. “The caller wants to create a new support ticket”).
“This outcome triggers an exit” (toggle)1

Steers the behavior of this outcome during the activity:

  • When enabled the outcome can be mapped to a dedicated Workflow exit on the “Add Virtual User” activity. Detecting it ends the conversation and steers the Workflow down the mapped path.
  • When disabled the outcome drives in-conversation behaviour only (e.g. capturing parameters) and does not end the Virtual User session.
Parameters Optionally attach up to 10 Parameters for storing customer-provided data. The AI decides which conversation data to write into them. 
💡The AI can immediately return the parameter contents back to the customer, e.g. to verify if it has correctly understood the instructions.

✅ Related Action

  • 1 At least one exit outcome must be defined on the Virtual User. It also needs to be mapped on the “Add Virtual User” activity before that activity can be saved. Otherwise the Virtual User would not know when to exit that activity
 

☝️ An exit-triggering outcome cannot be deleted while it is already used in any Workflow — the delete option is disabled to avoid breaking the Workflow.

 

Tools

💡These settings allow to extend the Virtual User with external system capabilities: MCP Server and Web Requests. They are optional, to be used either independently or together. Unselecting a tool keeps its stored configuration, so re-selecting it later restores everything you entered. Both are set up as separate configuration items (MCP Servers, Web Requests) and then selected on the Virtual User.

✅Precondition: Available when Bot Profile: “AI Workflow” or “Open Profile” were selected in the ”General" tab.

 

☝️PLEASE NOTE:

  • Failure Case handling: For both MCP and Web Request your Outcomes & Tools Instructions don't need to handle failure cases manually. This is done in the "Add Virtual User" Conversation Handling Activity. You can also define multiple → “Outcomes” and treat them each like a different case.
  • We highly recommend to limit and purpose-scope retrieved context via MCPs and Web Requests. If too many tools added, the Virtual User may slow down from tool usage or get the context wrong if too much data is provided. Also refer to our Best Practices - Virtual Users in Nimbus for further considerations.
 

Web Requests

Web Requests

A previously configured Web Request can be bound to the to the Virtual User, so the model can call it mid-conversation. Each binding has two fields on this page — the Web Request name itself, and an Instructions field that tells the model when to call it.

✅Precondition: Requires at least one configured configured Web Requests from the same (or a parent) Organization Unit where your Virtual User lives in.

💡Use this when …

  • … you want transparent definition and orchestration in Nimbus.
  • … the validation logic must be auditable directly in Nimbus.
  • … your called APIs are time-sensitive and tightly sequenced.
 

☝️Accounting for delays: Virtual User AI models are optimized for timely responses to a customer. A missing web request status code may be interpreted as “unresponsive”, which results in the “Failed” condition exit in Workflows being taken.

✅ Recommendation: When using AI-driven workflows, always enable “Wait for response” in your Web Requests > Response configuration. This is especially important when your AI workflow depends on the data being available. 

💡Of course “Wait for response” also means that long-running requests may incur a delay that the customer will perceive as silence from the AI. (Expected) long-running requests should therefore be announced to the customer beforehand. The Virtual User also re-engages the caller on its own after 10 seconds of silence, but this does not replace announcing the wait. Also, timeout exit codes are expected be sent by the target system so the AI knows when to move on.

 
Property Description
Web Request
(selection)

Each Web Request:

  • Is called directly from within the Nimbus configuration.
  • Uses HTTP Methods (POST, GET, PUT PATCH DELETE)-
  • Needs individual Headers / Authentication
  • Has Name fields for reference and…
  • Instructions fields for AI handling instructions.

☝️Outcomes & Tools Instructions dependency

  • Web Request Name / Instructions fields are used by the AI for reference during the Outcomes & Tools Instructions. 
  • The model will follow the order and logic you specify in the Instructions, not the order in which the Web Requests were added to the Nimbus UI.
    In the → Outcomes & Tools Instructions field, you should therefore clearly define HOW Web Requests are used in specific ORDER. 
 

💡Example: Unlike MCPs more capability-based flow, Web Requests should have a clear order sequence to the flow, as information retrieved can be often co-dependent, specific and granular. An example Web Request-centric flow description could therefore look as follows:

This workflow is designed to handle complex banking inquiries with multiple steps and dependencies.
The assistant will guide the customer through a series of questions to gather necessary information, 
validate it, and provide appropriate responses based on the detected Outcomes:.
 
The workflow should work as follows:
 1. Ask for the users bank name and validate it.
 2. Ask for the last 4 digits of the iban number and validate it.
 3. Ask for the users name name and validate it.
 4. Only when all the information is collected and validated, the assistant should proceed to answer the users inquiry based on the detected intent.
Instructions

This field tells the Virtual User how the Web Request is to be used.

☝ Note: The model does not see the Web Requests generic Description from its config page. Instead, use this Instructions field to describe it to the model.

💡The Instructions field should therefore also provide a precise description to the model, outlining the functional goals of the Web Request and necessary field descriptions to match with the customer conversation.

WEB REQUEST A (IBAN): For IBAN: “international bank account number (IBAN)”
WEB REQUEST B (Account): For Account Number: “bank-specific account number” (ACCT NO)
 
 

MCP Server

MCP Server

An MCP Server attaches a Model Context Protocol server endpoint to the Virtual User. Once attached, the server's tools are exposed to the model in real time during the call.

✅Precondition: Requires you to connect to a running, external MCP server, which offers more flexibility. The MCP server uses reusable Authentication configuration items — 🔎 also see Authentication in the property table row below.

💡Use this when…

  • …you already operate or connect to existing MCP servers.
  • …you want tools and capabilities to evolve independently of Nimbus, but constrain their usage.
  • …you want long‑term flexibility with less UI configuration.
 

🔎Notes

  • Scoped use: The AI model identifies each MCP Server by its Name and the Instructions. The individual tools inside the server are advertised by the server itself via the MCP protocol — Nimbus does not rename, scope or filter them in any way. If you require scoped access, you should limit the capabilities server-side – e.g. via proxy – to prevent any unwanted tools from being (e.g only READ, not WRITE).
  • Purpose | Order: The model will not follow the order in which the MCP servers were added into the Nimbus UI. In the general → Outcomes & Tools Instructions, you should clearly define “how” MCP tools are to be used. The AI decides the order of usage itself.
  • Good to know: Nimbus Virtual User is compatible with MCP servers designed for OpenAI GPT‑Realtime, including remote MCP servers exposed over HTTP. More information can be found in the OpenAI MCP connector guide and Realtime API documentation.
 
Property Description
Name

Each MCP server:

  • Uses the Model Context Protocol
  • Runs outside as server and is consumed by Nimbus, with an URL like: 
    https://<yourdomain.com>/mcp/
  • Uses available tools (discovered dynamically)

☝️The MCP Server “Name” Must be unique on the Virtual User. The model reads this name when deciding which server to call — use the same label inside the Outcomes & Tools Instructions (e.g. "use the JiraServer MCP Server to look up the ticket"). 

 
URL The MCP Server's SSE endpoint (e.g. https://jira.example.com/mcp/sse). Nimbus opens a streaming connection to this URL for every Virtual User session that uses the server. 
Instructions Free-text summary of what the server is for and when the model should reach for it (e.g. "Internal Jira instance. Use for any ticket lookup, comment, or transition."). 
Authentication

✅Requires a (reusable) Authentication configuration to secure the connection to the MCP Server. 

💡The dropdown lists the Authentications available in the Organization Unit of your Virtual User (and its parent units).

Supported authentication types:

  • API Key — a header name and secret key (the previous behaviour).
  • OAuth 2.0 (Client Credentials) — Nimbus requests and refreshes a bearer token automatically from your identity provider. The Authentication holds the Access Token URL, Client ID and Client Secret.

🔍 Notes: 

  • Authentications are defined once, then reused across all MCP Servers.
  • The Authentication dropdown loads even for administrators who can manage Virtual Users but do not have direct access to the Authentications configuration.
  • Secrets are stored encrypted in the Nimbus vault and never returned to the UI in clear text.
 
 
 
 

Notes

💡 Good to know

  • Testing: We highly recommend to do test-calls to your service and thoroughly for every Virtual User change, especially to test “unintentional” or “creative” user scenario approaches.
  • Customer barge-in behavior: Keep in mind that customers may interrupt the Virtual User mid-sentence and "barge-in" if needed to maintain more human-like conversational behavior. Your instructions should focus on mentioning important details first, or keep the Virtual User replies short.
 

✅ Follow-Up in other areas: 

  • In order to take effect, (licensed) Virtual Users must be added as a “Add Virtual User” Workflow Activity to your workflows.
  • Transcription and Summarization features are supported for Virtual Users, but not configured on the Virtual User itself — they are enabled per service in Service Settings → AI → Virtual Users. 
    ☝️ Note that: Summarization requires Transcription to be active, plus Virtual User data privacy consent on the tenant and customer transcription consent in the workflow. A separate “Record Consent” Conversation Handling Activity in your workflow can explicitly steer if a Transcript of the Virtual User interaction is generated (default is “Consent granted”).
  • Reporting: Virtual User Sessions are available in historical reporting via the OData Feed. Each session ends with one of the outcomes Successful, Failed, Timeout, Fallback or Customer Hangup, and the exit outcome taken in the workflow is recorded as well. Access requires the Virtual User Supervisor permission.
 

Configuration Scenarios

Scenario Comparison

A Virtual User is configured on three tabs: General, Behavior and Outcomes & Tools. The Bot and Profile you pick on the General tab decide which fields appear on the other tabs. Pick the scenario that matches your use case, then check the topics below it.

Route the caller

Route the caller: Intent Analyzer

Finds out what the caller wants, asks for missing details, confirms them and ends with the matching outcome. Your Workflow then routes the call. This profile does not use external tools.

Tab What to configure
General Bot: any Nimbus AI Service or Custom AI Service Bot. Profile: Intent Analyzer.
Behavior General Instructions: your company, the purpose of the call and what is out of scope. Then Messages, Timeouts (defaults: 180 s session, 45 s inactivity) and Voice & Language.
Outcomes For this profile the tab is called Outcomes. Fill in Outcomes Instructions, then add one outcome per routing target with This outcome triggers an exit enabled.

💡 The profile already confirms details with the caller and steers off-topic callers back. Don't repeat these rules in your instructions.

 
 

Self-Service

Self-Service: AI Workflow

Collects and confirms the details it needs, uses a Web Request or MCP Server to look something up or carry out an action, tells the caller the result and ends with an outcome. If a request can't be done with the tools you added, it ends with the AI Fallback.

Tab What to configure
General Bot: any Nimbus AI Service or Custom AI Service Bot. Profile: AI Workflow.
Behavior Same fields as for routing. Timeout defaults: 360 s session, 45 s inactivity.
Outcomes & Tools
  1. Outcomes & Tools Instructions: when to call each tool, in which order, what depends on what, and which outcome ends the call.
  2. Outcomes: at least one with This outcome triggers an exit enabled.
  3. Tools: enable Web Requests and/or MCP Server, add at least one, and give each its own Instructions.

💡 The profile already repeats collected values for confirmation, checks the spelling of names and emails, and takes long numbers in parts.

 
 

Flexible Setup

Flexible Setup: Open Profile

Minimal preset prompting for more flexibility: you write the persona, style and rules yourself. Use it only when Intent Analyzer or AI Workflow can't do the job.

Tab What to configure
General Bot: Custom AI Service only. Profile: Open Profile.
Behavior As for AI Workflow, plus Persona: Verbosity and Tone. Describe who the assistant is in the General Instructions rather than in the deprecated Role field.
Outcomes & Tools As for AI Workflow.

Add the rules the other profiles bring, one sentence each, if you need them:

  • Confirm: "Before calling a tool, repeat the collected values and wait for a yes."
  • Collect clearly: "Ask for one value at a time. Take long numbers in groups and confirm each group."
  • One language: "Speak only in the current language, including short acknowledgments."
  • No goodbye: "Never say goodbye or announce a transfer. A closing message plays automatically."
 
 

Copilot Studio agent

Copilot Studio agent

Your agent and its logic already live in Copilot Studio. Nimbus only connects the call to it.

Tab What to configure
General Bot: a Copilot Direct Line 3.0 Bot. Instead of a Profile, pick a Bot Response Template, which maps the agent's answer to your Workflow. Under Modalities, a Speech Recognizer is required.
Behavior Only Messages. Instructions, voice and language come from Copilot Studio and the Speech Recognizer.
Outcomes & Tools Not used. Exits come from the Copilot topics through the Bot Response Template.

☝ Speech-to-text adds noticeable delay. Prefer this option when natural conversation isn't the main requirement.

 
 

FAQ

What goes where

💡 Keep in mind: Write it once, where it belongs. When the same rule sits in two fields, the two versions can drift apart.

 
Field Put here Keep out
General Instructions
(Behavior, up to 10,000 characters) 		Who the company is, what the assistant is for, which services exist, what is out of scope. Tool names and order, greetings, goodbyes.
Initial / Final Message to Customer
(Behavior, up to 500 characters each) 		The exact words spoken at the start and at the end. Instructions to the model. They are spoken as written.
Outcomes & Tools Instructions
(Outcomes & Tools, up to 5,000 characters) 		When to call each tool, in which order, which depends on which, what to do when one fails, and which outcome ends the call. Company background, persona.
Instructions of an outcome, Web Request or MCP Server
(up to 1,024 characters each) 		When to use this one item, in one or two sentences. The order between tools.

💡 Parameters can be used as placeholders in the instructions and messages. They are filled in when the session starts.

 
 

Messages, timeouts and silence

💡 Keep in mind: 

  • Messages are spoken word for word, in the language active at that moment. The model doesn't add to them and doesn't remember them as part of the conversation.
  • Don't script a greeting or goodbye in the instructions. The caller would hear it twice.
  • Keep the Final Message neutral, e.g. "Thank you, one moment please." It plays after the outcome is chosen, so it can't know what happens next in the Workflow.
 
Timeout Default Range When reached
Max Session Duration 180 s (Intent Analyzer)
360 s (other profiles)		 30–1,800 s A fixed end message plays and the Workflow continues on the Idle Timeout exit.
Inactivity Timeout 45 s 5–3,600 s

🤫 When the caller goes quiet, the Virtual User speaks up after 10 seconds and again after a further 10 seconds, e.g. by asking whether the caller is still there. If there is still no reply, the Idle Timeout exit is taken once the Inactivity Timeout has elapsed; both attempts count toward it. The 10-second interval is fixed and cannot be configured. While a tool is still running, the wait doesn't count, so a slow tool never ends the call.

 
 
 

Language and voice

💡 Keep in mind: 

  • Start language: the Language field sets the language the Virtual User starts in.
  • Switching: it changes language only when the caller explicitly asks, e.g. "Can we continue in French?". It never switches because of an accent or a foreign word.
  • No own language rules: all profiles handle switching already. Additional rules compete with them. If you want callers to choose, add one line such as "After the greeting, ask whether the caller prefers English or French."
  • Voice: stays the same for the whole call. With Azure Voice Live Bots, the voice list depends on the selected Language.
 
 
 

Outcomes and Tools

Your AI gets more effective when you expand the capabilities with external tools. When the bot's job involves calling an external system, the way you describe each tool decides whether the model uses it well, ignores it, or misuses it.

✅ Three-sentence template for the tool instructions:

  1. What it does — "Looks up an order by order number in the e-commerce backend."
  2. When to call it — "Call this whenever the caller asks about the status, delivery date, or contents of a specific order."
  3. What you'll get back — "Returns the order status, expected delivery date and line items, or an empty result if the order number is unknown."
 

💡 Keep in mind: 

  • Tools must exist first: only mention tools that are actually added. A rule about a missing tool confuses the model and may lead to failed workflow outcomes.
  • One tool, one job. A customer_lookup and a separate order_lookup are far easier for the model to reason about than one omnibus customer_or_order_lookup.
  • Exact names: the model sees names in lowercase with spaces replaced by _ and special characters removed ("Check Balance!" becomes check_balance). Use that form in your instructions.
  • Tool Instructions are what the model sees. Each Web Request and MCP Server added to a Virtual User has its own Instructions field. The model does not see the generic Description of the Web Request or MCP Server configuration item.
  • Read-only first. If a tool can both read and write, start read-only and add write capability only once the read path is validated.
  • Confirm before destructive actions. Encode "confirm with 'yes' before you make the change" rules in the Outcomes & Tools Instructions for any write-capable tool.
  • Parameters: attach up to 10, and only what the next Workflow step needs. Give each Parameter its Virtual User Instructions. A warning icon shows on outcomes where they are missing.
  • Outcome Name: a short verb phrase, e.g. route_to_billing, up to 64 characters. Names must be unique across outcomes and tools.
  • Failure handling lives in the activity, not the prompt. Tool errors take the Failed exit of the Add Virtual User activity — you don't need to write fail-safe branches into every instruction step. Reserve the prompt for graceful behavior (apologize, offer a transfer) once a tool returns an empty result.
    • Exit or not: enable This outcome triggers an exit for results that end the call. Leave it off for steps that only collect or return information.
    • AI Fallback: always added automatically. It is taken when nothing fits the request, the caller stays off topic, or data collection keeps failing.
 

☝ IMPORTANT — descriptions can leak. Anything you put into a Web Request name, its Instructions or an MCP Server name is shown to the language model — and the model can be coaxed into repeating it. Don't put secrets, internal URLs or confidential context there.

 
 
 

Chaining Virtual Users

💡 Keep in mind: 

  • When one Virtual User's exit leads to another later in the Workflow, the second one starts a brand-new conversation.
  • Good fit: clearly separate phases (identify the caller, then handle the request), or a non-AI step such as a queue in between.
  • Avoid: splitting one task just to keep instructions short. The pause and the lost context usually cost more. One Virtual User with more outcomes often does the job.
  • If you chain: save everything later steps need as Parameters, keep later greetings short, and test the whole chain end to end. Each Virtual User needs its own license.
 
Carries over Is lost or restarts
  • Parameters saved on the exit.
  • The exit that was taken.
  • Everything only spoken in the conversation.
  • A language the caller switched to.
  • Timeouts, greeting and voice.
 
 

Troubleshooting the Failed exit

💡 Keep in mind: When the Add Virtual User Conversation Handling Activity takes the Failed exit, check:

  • Data Privacy Tenant Settings : the Virtual User is allowed for the tenant and its data privacy consent is given.
  • License Management: the Virtual User has an active license assigned on its General tab.
  • Profile and Bot: the Bot supports the profile, e.g. Open Profile needs a Custom AI Service Bot.
  • Exits: every exit outcome of the Virtual User is mapped on the activity. 
    💡 Calls that end early or lose their connection to the AI service also take the Failed exit.
 
 
 

Limitations

General note on AI-driven interactions

AI driven replies are very dependent on what the Customer is saying. For example, if the Customer is saying “I have trouble with my modem” it is not necessarily given that the bot will associate “Internet” as your workflow routing exit, unless specifically handled in your Virtual User integration and instructions. We therefore highly recommend to test and account for “creative” or “non-tech-savvy” wording when designing your Virtual User interactions within your workflows.

🔎Recommended reading for beginners: We collected and wrote down some Best Practices - Virtual Users in Nimbus to help you with considerations and risks when replaying human interaction with AI.

 

General Virtual User limitations

The current Nimbus implementation with AI-driven bots underlies the following limitations: 

  • Supported Modalities: Virtual Users (Bots) are currently available for Audio/Video modality tasks.
  • Virtual User Reporting: Sessions involving Virtual Users are not reflected as dedicated User Session. Virtual User session reporting is planned for a later point this year.
 
 

Microsoft Copilot Limitations

  • Expect processing delays: Processing AI answers takes a few seconds for voice-to-text-transcription, followed by AI processing and then the same transcription back into a voiced response. Luware is trying to minimize the delay on Nimbus call infrastructure, but the dependency on external APIs will always incur this delay. The Customer will hear silence during this processing and no audio feedback / silence detection.
  • Ensure you have no ambiguity in your topics. For instance, the word “Service” may be too generic if you want to transfer to different services. Rather use healthcare|medical|emergency as identifiers or use more complex Regular Expressions to identify replies.
 
 

Nimbus AI Services Limitations

Bot Configuration Profile 🔎 Design Notes (not limitations)
AI Workflow
  • Failed condition: If either a Web Request connection or MCP server connection fails, the “Failed” workflow activity exit will be taken immediately.  Also applies for any other Nimbus-internal or technical error.
  • Fallback condition: Any “Fallback” parameters will be updated with the response generated by the AI when a case cannot be handled.
Open Profile
 
 

Virtual User Configuration Assistant (Companion) Limitations

  • Nimbus AI Services only: The configuration assistant can only create and update bots and Virtual Users for Nimbus AI Services. Bots of type Custom AI Services must be configured manually.
  • Tools: Tools for the AI Workflow profile are limited to Web Requests. MCP tools aren't supported yet. The Web Requests must already exist. If they don't, Companion offers to save your progress so you can create them manually.
  • Permissions: If you don't have the permissions to create or update Virtual Users, the organization unit drop-down menu in the form is empty. No further message explains this.
  • Language: Companion doesn't ask for a language. New Virtual Users are created with English as the default language.
 
 
Conversation Handling Activities

This page lists all Workflow activities that relate to customer interaction, e.g....

Bots

A Bot is the connection between Nimbus and the AI service that drives a Virtual U...

Use Case - Setting up a Nimbus Virtual User using Copilot

PREVIEW - This Use Case showcases features that may not yet be available to all c...

Speech Recognizers

Speech Recognizers are a piece of software that transcribes audio to text. You ca...

Table of Contents