The challenge when building Virtual Users in Nimbus isn't just about building intelligent agents — it's about building the right kind of intelligence. In the pursuit of efficient, scalable and secure customer service experiences, simplicity and focus often outperform complexity.
This article collects best practices for creating Virtual Users in Nimbus, guided by three key principles: simplicity, modularity and workflow-based design. Rather than developing large, all-knowing bots, we advocate for small, purpose-built agents that handle clearly defined tasks. This "separation of concerns" makes systems more maintainable, reduces the surface area for security risks and improves performance.
By thinking in terms of workflows, starting from user intent, and prioritizing interactions based on urgency and context, Virtual Users can more accurately triage requests, automate low-value interactions, and escalate high-value ones to the right human agents. These agents should act as advisors, not decision-makers — providing data, context and next steps without replacing human judgment.
Glossary
| Term | Definition |
|---|---|
| Virtual User | AI-powered assistant that interacts directly with customers — greets the caller, captures context parameters, and hands the conversation result back to a Nimbus Workflow. |
| Bot vs. Agent Type | A Bot in Nimbus describes where the AI runs — Nimbus AI Service (Luware-hosted) or Custom AI Service (bring-your-own). The Agent Type selects the underlying technology — Azure OpenAI or M365 Copilot Direct Line 3.0. Together they decide which Profile options become available on the Virtual User. |
| Profile | Selected on the Virtual User. Decides how the bot behaves in the conversation — Intent Analyzer, AI Workflow or Open Profile. Hidden for Copilot bots (the conversation is fully driven by the Copilot Studio Agent). |
| Tools | Web Requests and MCP Servers attached to the Virtual User. Available on AI Workflow and Open Profile. |
| Outcomes & Tools Instructions | Per-Virtual-User playbook that tells the model how to drive the conversation toward its outcomes and when Tools are involved. |
| Generative AI | Systems that create new content (text, audio) by learning from existing data. |
Benefits & Challenges
Using Bots as Virtual Users in your workflows brings clear benefits, but also challenges.
| Benefits | Challenges |
|
|
Choosing your AI
Where a human would apply judgment, pattern recognition or creativity, you have to decide which kind of AI to throw at the problem. Not all AI is the same — and the right choice depends on the task.
| Aspect | 👓 Non-Generative AI | ✍ Generative AI | 🧠 Orchestration |
|---|---|---|---|
| Core Function |
Classify, recognize, recommend Structured tasks like classification, routing or scoring using predefined logic or trained models. |
Create, personalize, react flexibly Creates new content — summaries, responses, translations — using large language models. |
Delegate, coordinate, contextualize Orchestrates tools, agents and AI models to decide what to do and in what order. |
| Behavior | Deterministic rules or trained models return specific outputs. | Human-like responses based on context and user input. | Decides which AI component to invoke, when and how. |
| Nimbus mapping | Intent Analyzer profile. | AI Workflow profile (with optional Tools) and Open Profile. | Copilot Studio agents (Direct Line 3.0), and Generative orchestration in Copilot Studio when enabled. |
| Strengths | Precision, reliability, speed | Creativity, adaptability, personalization | Flexibility, scalability, coordination |
| Limitations | Limited to predefined tasks. Cannot go off-script. | Can produce incorrect responses. May hallucinate. | Adds latency. Complexity can slow performance and complicate monitoring. |
✅ How to approach the choice
☝ GenAI (with or without Orchestration) can cause noticeable delays — customers experience them as pauses or silence during the interaction. Test the experience end-to-end before committing.
In Nimbus, we want to use controlled generative AI — combining deterministic with non-deterministic logic.
- Prefer Intent Analyzer for any task that is "really just routing".
- For AI Workflow / Open Profile, keep Tools narrow and the Outcomes & Tools Instructions short and explicit.
- For Copilot Studio, enable generative AI only in single Topics rather than globally — this acts as a control mechanism.
- Add additional topics for human hand-over when an approval is needed.
- Test thoroughly before going to production — customers can get equally creative.
Privacy, Security & Cost
Conversations
Conversation Privacy
☝ Keep in mind: the conversation between a customer and a Virtual User can contain private or sensitive data.
Output from Bots can be mapped to Parameters that appear in Sessions List and My Sessions. When Context Handover is enabled, these parameters can travel across multiple Nimbus services. Nimbus deletes session parameter data after the retention period described in our Documents whitepapers; permanent storage is the customer's / administrator's responsibility.
💡 Good to know: Nimbus itself does not store the exchanged conversation messages or parameter data in any log file.
💡 Tools: when the Virtual User calls a Web Request or MCP Server, the request payload and response stay between Nimbus and the external system. Treat those systems with the same data-handling discipline as any other integration.
Permissions
Bot Permissions
☝ Keep in mind: a bot can be coaxed into divulging customer data when asked correctly.
It is tempting to point an AI at a large dataset and let it answer anything. Real-world incidents have shown that even sophisticated bots can be "convinced" to reveal sensitive information. Limit permissions and accessible data as much as possible.
💡 Hint: use the Nimbus Power Automate Connector to fetch data (CRM, repositories, external systems) and provide it as Parameters — correct, scope-limited and up-to-date, with access privileges under Administrator control.
💡 Tools — least-privilege scoping: when you attach a Web Request or MCP Server, give it the narrowest possible scope. Read-only beats read-write; one record at a time beats bulk; bind credentials at the Authentication record (rotatable in one place) rather than embedding them per Virtual User.
Running Costs
Running Costs — Third Parties
☝ Keep in mind: everything a Virtual User does is tied to a cost — a little like with employees. Re-check the pricing of your external AI suppliers regularly.
The Virtual User is meant to drive down operational costs — but the AI itself isn't free. Some points worth thinking through:
- AI vs. plain automation — does this task really need a language model, or can a deterministic flow handle it?
- Generative vs. non-generative AI — classification (intent recognition) is cheaper and more predictable than free-form generation.
- Nimbus AI Service vs. BYO Azure OpenAI — Nimbus AI Services are managed by Luware, with no additional hidden cost per-call, e.g. in your Azure billing (also see Note below).
- Profile selection — Intent Analyzer is the cheapest end-to-end (short, focused prompts). Open Profile with Tools is the most expensive and slowest. Pick the simplest profile that fits.
Picking your Profile
The single most consequential decision when building a Nimbus Virtual User is the Profile. Each Profile has a sweet spot and a set of guardrails — picking the right one saves you from fighting validation rules later. The configuration scenarios below the matrix show which fields each choice needs.
Comparison
Configuration Scenarios
Examples
💡 The examples below cover the most common task shapes across the Virtual User Profiles and Copilot Studio. For technical details and step-by-step instructions, head to our AI Use Case Category.
Example A: Order Status Bot (AI Workflow + Web Request)
Example A: Order Status Bot — AI Workflow profile with a single Web Request
A Virtual User on the AI Workflow profile, with one Web Request, Order Lookup, added and Web Requests enabled. The model sees it as order_lookup, so the Outcomes & Tools Instructions use that name:
1. Ask the caller for their order number. 2. Call order_lookup with the order number provided. 3. If order_lookup returns a result, read back the order status and the expected delivery date. 4. If order_lookup returns no result or an error, apologize and end with the transfer_to_agent outcome. 5. After confirming the status, ask whether there is anything else. If not, end with the status_given outcome. Never invent an order status. Only state what order_lookup returns. |
- Workflow exits: status_given → Disconnect. transfer_to_agent → Queue. AI Fallback → Queue (the Fallback Parameter carries the AI's summary). Failed → safe fallback (Queue / Voicemail). Idle Timeout → Voicemail.
- Final Message to Customer: "Thank you, one moment please."
🔎 Full step-by-step: Use Case - Integrating Nimbus Virtual Users with External Systems.
Example B: Callback Assistant (Copilot)
Example B: Automated Callback Assistant
An Agent called "Callback Assistant" recognizes the customer's intent to request a callback. It can…
- … check if a call has already been scheduled for a phone number and inform the customer about the details.
- … schedule a Nimbus Outbound Call in the future, e.g. by using the Power Automate Connector and Flow Actions.
🔎 Full step-by-step: Use Case - Building a Callback Assistant in Copilot.
Example C: Customer Feedback Agent (Copilot)
Example C: Customer Feedback Agent
An Agent called "Customer Feedback Agent" checks in at the end of a call to ask about service satisfaction. It can…
- … recognize and categorize feedback (sentiment, topic, suggestions) and …
- … send the feedback to the survey backend system.
The Copilot does not need general AI to be enabled — it works with controlled deterministic topics. Only the "Give Feedback" topic uses generative AI to interpret the caller's natural-language feedback, via Power Automate.
🔎 Full step-by-step: Use Case - Building a Nimbus Survey Agent in Copilot.
Access & Oversight
Like every employee, a Virtual User needs specific permissions — access to systems, data and tools — and benefits from checkpoints when decisions have consequences.
- Just enough access. A well-designed Virtual User has the minimum access needed to do its job. Ask: "Does it need to send data to Nimbus or store data in a CRM record or a survey document?"
- Approval where it matters. Just as a person might need sign-off, bots benefit from supervisory checkpoints when decisions are uncertain or consequential. Ask: "What is the impact if the bot writes incorrect data to the CRM? Do I want a human approver in the loop, and at what step?"
Voice Channel Realities
A Virtual User on a phone call is fundamentally different from a chat bot. These rules of thumb pay back many times over:
- Brevity wins. TTS playback is linear time the caller has to sit through. Cap replies at 2–3 sentences in the General Instructions, and set Verbosity = Concise on Open Profile bots. Long TTS playback is the most common reason a bot "feels slow".
- Silence ≠ engagement. When the bot is thinking or calling a tool, the caller hears nothing. Long tool chains compound the silence. If a tool is slow, consider whether the value of calling it survives the perceived latency.
- Hand-offs feel abrupt. Use a neutral Final Message to Customer ("Thank you, one moment please.") so a transfer feels intentional, not dropped. It plays before the Workflow continues, whichever exit is taken.
- Voice is a matter of testing. The right voice depends on your service, audience and how much text the bot speaks. Test with your target group. Available voices come from third-party AI services and can change over time.
Test & Iterate
- Happy-path first. Make sure the bot does the right thing for the 3–5 most common caller intents.
- Adversarial second. Try wrong inputs, missing data, off-topic detours, and "can you forget your instructions" prompts.
- Tool-failure scenarios. Disable an upstream Web Request briefly and verify the bot follows the failure rules of your Outcomes & Tools Instructions rather than inventing data.
- One change at a time, several runs each. Small wording changes can change the behavior a lot, and the model doesn't answer identically on every call. Repeat each scenario a few times after every edit.
- Iterate on the cheapest dial first. Outcomes & Tools Instructions > tool Instructions > General Instructions > tool design > Profile change. Changing the Profile is the most invasive — exhaust the cheaper dials first.
- Announcement & Disconnect safety net. Temporary Announcement activities at exit nodes make it easy to see which exit was taken and which Parameters were populated.
Final Thoughts
Stay in the AI-employee mental model: think of granting some freedom within a playbook. Your AI can improvise, but not go off-script. Larger decisions require supervision. Designing Virtual Users as if they were employees — with defined roles, boundaries and oversight — keeps your systems understandable, trustworthy and effective. Not every Virtual User needs AI. Not every decision needs creativity. But where automation meets intelligence, and where intelligence meets judgment, the design must be intentional.
Limitations
Below are our currently known issues and limitations for Virtual Users in Nimbus. We strive to improve our AI feature support with each future Nimbus release, so make sure to check back regularly and visit our Latest Release Notes for updates.