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

Benefits & Challenges

Using Bots as Virtual Users in your workflows brings clear benefits, but also challenges.

Privacy, Security & Cost

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

Design Principles

When building Bots as the "engine" behind your Virtual User, treat them as employees, not as pieces of software. Each bot should have:

• A clear role.
• A clear set of task responsibilities and the skills required to fulfil them.
• A defined level of autonomy with limited permissions on a "need to know" basis — just like a person on a team.

This simple mental model keeps your bot design maintainable, controllable and purpose-driven.

Start with the Role

Before configuring anything, ask: What job will this Virtual User do?

• Is it answering questions? What kind, and how broad is the topic?
• Does it need specific data? List the data points needed and where they live.
• Can you anticipate the caller's wording? What synonyms might come up for the same intent?
• Tickets? Create, look up, update?
• Escalation or transfer? When and to whom?

Shape the Persona

Virtual User offers several fields that together shape who the bot is and how it speaks. The accordions below expand each with a concrete example.

You are a Front Desk Operator for an insurance company.
Greet the caller by name if $(Customer.Name) is available, otherwise greet politely.
Speak in the caller's language. Keep replies to 2-3 sentences.

Hard rules:
- Never quote a policy number you have not verified through a tool.
- Never confirm a claim status from memory — always look it up.
- If the caller mentions a complaint, offer to transfer to a human agent.

Role:      Order Support Agent
Tone:      Friendly and professional, never pushy
Verbosity: Concise

1. Greet the caller and ask for their order number.
2. Call the OrderLookup Web Request with the order number provided.
3. If OrderLookup returns a result, read back the order status 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.

Break Tasks Down

Once the role is defined, map the sequence of tasks the Virtual User needs to perform. A task can usually be broken into repeatable steps, each triggered by an event (caller input, schedule). Real processes are non-linear — conditional branches, exceptions, parallel actions — and the Virtual User should be prepared for those variations while staying within clearly defined bounds.

Examples

1. Greet the caller and ask for their order number.
2. Call the OrderLookup Web Request with the order number provided.
3. If OrderLookup returns a result, read back the order status 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 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.

 

 

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

• One tool, one job. A CustomerLookup + a separate OrderLookup is far easier for the model to reason about than one omnibus CustomerOrOrderLookup.
• Name the tool the way you reference it in the Flow Description. The label the model sees on a Web Request is the Web Request's Name; on an MCP Server it is the MCP server's Name. Reuse the exact same name when telling the bot to call it.
• Web Requests vs MCP Servers — where the description lives: Web Requests use the per-binding AI Description on the Virtual User (overridable per VU). MCP Servers use the server-level Description (shared across every VU that binds the same server). To customize per-VU behaviour for an MCP Server, adjust the Flow Description instead.
• 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 Flow Description for any write-capable tool.
• 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 Flow Description step. Reserve the prompt for graceful behaviour (apologize, offer transfer) once a tool returns an empty result.

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 to 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. Three 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 System Instruction, and set Verbosity = Concise on Open Profile bots.
• 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 the Closing Message field to signal a hand-off ("Connecting you now…") so a transfer feels intentional, not dropped.

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.

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 Flow Description's failure rules rather than inventing data.
• Iterate on the cheapest dial first. Flow Description > AI Description on the tool binding > System Instruction > 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 are 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.