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 customers - greeting the callers, capturing context parameters and handing the conversation result back to Nimbus Workflow.

INC Preview Feature

This feature is in PREVIEW and may not yet be available to all customers. Functionality, scope and design may change considerably.

INC AI and Virtual User Preconditions

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

💡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 Companion 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 typ and profile should therefore be chosen with the intended use case in mind.

INC Language model comparison matrix

Defined in Bots		Defined in Virtual Users
Type Nimbus managed or BYO	Agent Type Underlying LLM	Virtual User Profile Pre-built configurations to fulfill a certain use case
Nimbus AI Service	Azure OpenAI¹	Intent Analyzer - Intent Analysis Use Cases. AI Workflow* -* Extending Virtual User with additional external system capabilities (MCP or Web Request) and handle the response directly in Nimbus Workflows
Custom AI Service	Azure OpenAI¹	Intent Analyzer - Intent Analysis Use Cases. AI Workflow* -* Extending Virtual User with additional external system capabilities (MCP or Web Request) and handle the response directly in Nimbus Workflows Open Profile - Same as AI Workflow, but with additional controls over Verbosity, Tone, Role
Custom AI Service	M365 Copilot Direct Line 3.0	No Profile shown — you need an Agent in Copilot Studio to handle Topics and map responses to Bot Response Templates. Also see Use Case - Setting up a Nimbus Virtual User using Copilot.

Notes

¹Due to Microsoft Azure AI foundry availability in limited regions, data processed by a Nimbus Virtual User “GPT”-Realtime" integration might temporality leave 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:

Bot Response Templates, to map bot answers back into Nimbus workflow parameters.
Speech Recognizers (Transcribers) to convert the Customer voice into text for the bot to process.

🔎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 is non-exhaustive; pick the closest pattern and adapt it.

Ticket triage	Intents Create Ticket, Check Status, Escalate — each routed to its own downstream flow.
Identification gate	Intents Identified, Not Verified, Fraud Suspected — personalised self-service vs. manual verification vs. priority security queue.
FAQ with escalation	Intents Answer Found, Low Confidence, User Requests Agent — answer in-bot, offer alternative handling, or hand straight to an agent.
Payment / transaction	Intents Successful, Failed, User Aborted — confirmation, retry, or graceful exit.
Password reset	Intents Reset Successful, Reset Failed, User Locked Out — confirmation, retry, or escalation to support desk.
Survey	Intents Completed, Partial Completion, Drop Off — thank-you message, follow-up, or callback workflow.
Card blocking	Intents Card Blocked, Identification Failed, User Cancelled — confirmation with audit log, high-priority escalation, or safe exit.

General Information

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.

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.

Bot Configuration

✅Requires a “Organization Unit” to be selected.

The Bot dropdown drives a follow-up Profile dropdown. Based on the bot and profile choice, visible options change the configurable fields further down this page.

Bot

✅Pick a previously configured Bot.

🔎More details on the different Bot and Agent models can be found in the Preconditions above.

💡The Bot's service and underlying AI Agent model determine which Profile options become available.

Profile

✅ Required (except for Copilot bots).

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 controls over Verbosity, Tone, Role

💡The choice automatically changes the visible properties further below.

Bot Response Template

(only for Copilot Bots).

Bot Response Templates map the JSON response your Bots (external APIs) deliver, with the goal to use that response as criteria within your Workflows.

AI Behavior

Property	Description	Notes
Role (Open Profile only)	Short label describing the persona the bot plays (e.g. "Customer service representative", "Pharmacy advisor"). Used as a building block of the system prompt so admins do not have to re-write the role into every System Instruction.	✅Only visible when “Open Profile” was selected as bot configuration
Verbosity (Open Profile Only)	Short label describing how chatty the bot should be: Concise Balanced Detailed
Tone (Open Profile Only)	Short label describing the desired conversational tone (e.g. "Friendly and professional", "Concise and factual"). Combined with Role and Verbosity to colour the bot's style.
System Instruction	Free-text prompt that defines the bot's persona, domain knowledge and rules.	10,000 chars limit Supports Custom Parameters and System Parameters

Conversation Messages

Property	Description	Notes
Initial Message	First thing the caller hears when the Virtual User joins. Free-text prompt that defines the bot's persona, domain knowledge and rules. 💡When the Virtual User is invoked from Outbound Call with Workflow, this is the message played when the called party picks up.	500 chars limit Supports Custom Parameters and System Parameters
Closing Message	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.	500 chars limit Supports Custom Parameters and System Parameters

Property

Description

Notes

Initial Message

First thing the caller hears when the Virtual User joins.

Free-text prompt that defines the bot's persona, domain knowledge and rules.

💡When the Virtual User is invoked from Outbound Call with Workflow, this is the message played when the called party picks up.

500 chars limit

Supports Custom Parameters and System Parameters

Closing Message

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.

500 chars limit

Supports Custom Parameters and System Parameters

Voice & Language

Property	Description	Notes
Language / Voice	Optional spoken-language and voice selection. 💡Not available for Copilot Bots, which are configured via Speech Recognizers instead.	Selection limited by Bot choice.

Property

Description

Notes

Language / Voice

Optional spoken-language and voice selection.

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

Selection limited by Bot choice.

☝️Phase-out: The voice “Fable” is not supported anymore by OpenAI. It will be removed in the next release.

Timeouts

Property	Description	Notes
Session Timeout	Maximum total duration the Virtual User stays in the call.	seconds
Idle Timeout	How long the bot waits for caller input before taking the Idle Timeout exit.	seconds

Extension Tools

💡These settings allow to extend the Virtual User with external system capabilities.

✅Precondition: Visible when “Nimbus AI Services - AI Workflow” Bot was selected as part of the previous “Bot Configuration”.

Flow Description

Property	Description
Flow Description	The Flow Description is 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 write a good Flow Description

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 system Instruction (role, tone, language). The Flow Description is about the technical information flow, not personality.

☝️Note: The following examples are reference points, not functionally verified.

Example 1 — Web-Request-only Virtual User (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 Virtual User (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.

Web Requests

A Web Request binding attaches a configured Web Request 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 AI Description 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.

Property Description

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… AI Description fields for AI handling instructions. ☝️Flow Description dependency Web Request Name / Description fields are used by the AI for reference during the Flow Description. Important: The model will follow the order and logic you specify in the Flow Description, not the order in which the Web Requests were added to the Nimbus UI. In the → Flow Description field, you should clearly define how Web Requests are used in sequence. 💡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 intents. 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.
AI Description	This field tells the Virtual User how the Web Request is to be used ☝ The model does not see the Web Request's generic Description from its config page. Use the AI Description below to describe it to the model. 💡The AI Description 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)`

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…
AI Description fields for AI handling instructions.

☝️Flow Description dependency

Web Request Name / Description fields are used by the AI for reference during the Flow Description.

Important: The model will follow the order and logic you specify in the Flow Description, not the order in which the Web Requests were added to the Nimbus UI.

In the → Flow Description field, you should clearly define how Web Requests are used in sequence.

💡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 intents.
 
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.

AI Description

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

☝ The model does not see the Web Request's generic Description from its config page. Use the AI Description below to describe it to the model.

💡The AI Description 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

An MCP Server attaches a Model Context Protocol 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.

💡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.

💡 The model sees each MCP Server by its Name and Description. The individual tools inside the server are advertised by the server itself over the MCP protocol — Nimbus does not rename or filter them.

💡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 Headers and API keys for authentication Uses available tools (discovered dynamically) ✅Required. 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 Flow Description (e.g. "use the `JiraServer` MCP Server to look up the ticket"). 💡In the → Flow Description, you should clearly define how MCP tools are to be used. The model will follow the order and logic you specify in the flow description, not the order in which the MCP servers were added.
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.
Description	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."`).
Header Name	The HTTP header under which Nimbus sends the API key on every request to the MCP Server (commonly `Authorization`, `X-API-Key`, or a vendor-specific header).
API Key	The secret value sent in the configured header. Stored encrypted in the Nimbus vault and never returned to the UI in clear text — only a masked preview is shown after saving.

Failure Case behavior

💡Good to know: For both MCP and Web Request your flow description doesn't need to handle failure cases manually. This is done in the "Add Virtual User" Conversation Handling Activity.

Show Details about the WF Activity…

Add Virtual User

INC Preview Feature

This feature is in PREVIEW and may not yet be available to all customers. Functionality, scope and design may change considerably.

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.

☝Note: 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

Known Limitation: While all Virtual Users are planned to be fully supported by Outbound Call Workflows, a prior “Announcement” workflow activity is required before the “Add Virtual User” to give the AI sufficient spin-up time

License

Advanced Routing

Enterprise Routing

Contact Center

Modalities

Audio / Video

Instant Messaging

External Task

Common Properties

Virtual User activity properties with **Copilot Direct Line** as underlying model

Audio / Video

INC WF Properties remark

No specific behaviors for this modality. “Common Properties” apply.

Modalities

Property	Description
Modalities	Enables the bot to handle and react to Audio/Video (calls). ⮑ Depending on your chosen bot, checking this option may require a Speech Recognizer to be configured → See below. 💡Further modalities will be made available in the near future.
Speech Recognizer	✅Preconditions: Copilot Direct Line 3.0 was selected as a Bot. Requires 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.

Property

Description

Modalities

Enables the bot to handle and react to Audio/Video (calls).
⮑ Depending on your chosen bot, checking this option may require a Speech Recognizer to be configured → See below.

💡Further modalities will be made available in the near future.

Speech Recognizer

✅Preconditions:

Copilot Direct Line 3.0 was selected as a Bot.
Requires 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.

Licenses

Property	Description
Licenses	✅You may need to store and re-open your Virtual User configuration before you can re-apply a license. ✅In order to take action within a workflow, every individual Virtual User needs a license applied. You may freely (re-)assign licenses from your License Management. If you require additional licenses, get in touch with Luware Customer Success.

Property

Description

Licenses

✅You may need to store and re-open your Virtual User configuration before you can re-apply a license.

✅In order to take action within a workflow, every individual Virtual User needs a license applied. You may freely (re-)assign licenses from your License Management. If you require additional licenses, get in touch with Luware Customer Success.

Follow-up Steps

✅Follow-Up:

In order to take effect, Virtual Users must be added as “Add Virtual User” activity to your Audio/Video workflows.
We highly recommend to do test-calls to your service and thoroughly test every Virtual User change.

Limitations

INC AI and Virtual User Limitations

General note on AI-driven interactions

AI driven replies are not deterministic and depend highly on what the Customer is saying. For example, if the Customer is saying “I have trouble with my internet” it is not necessarily given that the Bot will associate “Router, Modem” as your workflow routing exit, unless specifically handled in your Virtual User integration. In this specific example, AI instructions should also cover alternative wordings like “Router, Internet”, to be handled in topics accordingly.

🔎Refer to our Best Practices - Virtual Users in Nimbus for some considerations and risks when using Virtual Users instead of Human interaction.

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 - Profile: Intent Analyzer

🔎By design (not a limitation or reportable issue):

The Nimbus Intent analyzer Bot runs on pre-defined prompts. Any usage outside of the descriptions specified under Use Case - Setting up a Nimbus Virtual User for Intent Analysis is not supported.
Fallback handling: If a workflow uses exits with multiple parameters, e.g. to collect customer name and invoice number, and only one parameter can be retrieved, the fallback exit is taken.

Nimbus / Custom AI Services - Profile: AI Workflow

🔎By design (not a limitation or reportable issue):

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.

☝️Current limitations, coming with a later update:

For this profile there currently are no custom exits in the “Add Virtual User” Conversation Handling Activity. You only have Success, Fallback, Failed, Idle timeout.
There is currently no support for custom Parameters in “Add Virtual User” Conversation Handling Activity.

Custom AI Services - Profile: Open Profile

☝️Current limitations, coming with a later update:

The use of Extensions Tools (either Web Request or MCP Server) is currently mandatory in this profile. 💡This will be improved in a future update to allow for no tools to be used.
For this profile there currently there are no custom exits in the “Add Virtual User” Conversation Handling Activity. You only have Success, Fallback, Failed, Idle timeout.
There is currently no support for custom Parameters in “Add Virtual User” Conversation Handling Activity.

Luware Knowledge

Luware Nimbus

Luware Recording

Resource Library

INC Preview Feature

INC AI and Virtual User Preconditions

PRECONDITIONS: AI Features, Bots and Virtual Users

Admin Consent: AI Features

Virtual User Licensing

Virtual User Bot Configuration

INC Language model comparison matrix

Notes

Use Cases

General Information

Bot Configuration

AI Behavior

Conversation Messages

Voice & Language

Timeouts

Extension Tools

Flow Description

💡How to write a good Flow Description

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

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

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

Web Requests

☝️Flow Description dependency

MCP Server

Failure Case behavior

Show Details about the WF Activity…

Add Virtual User

Add Virtual User

INC Preview Feature

Common Properties

🔎Notes

For Copilot

For Nimbus Audio Intent Analyzer / Audio GPT Realtime

Audio / Video

INC WF Properties remark

Modalities

Licenses

Follow-up Steps

✅Follow-Up:

Limitations

INC AI and Virtual User Limitations

General note on AI-driven interactions

General Virtual User limitations

Microsoft Copilot Limitations

Nimbus AI Services - Profile: Intent Analyzer

Nimbus / Custom AI Services - Profile: AI Workflow

Custom AI Services - Profile: Open Profile

Related Articles