In this Use Case we're setting up a Virtual User to determine the intent of a customer in a direct conversation, store the customer intent directly into parameters and analyze the intent directly for call routing. 

To achieve this, we're going to cover the following topics in this Use Case: 

• How to configure Nimbus in order to use the Virtual User in your workflows.
• How to configure parameters, to instruct the Virtual User AI on how to select parts of a customer's requests as stored data.
• How to set up the workflow and make service calls for further adjustments.

Preconditions

Use Case Overview

Details will be covered below in this Use Case. As a quick tl;dr, here is an overview of items you will need: 

Step 1 - Nimbus AI Bot Setup

Configuring the Bot

✅ The Bot is your “mapping” to the AI service that hosts the conversation.

1. Head to Nimbus Administration > Configuration > Bots and create a new Bot.
2. Give your Bot a descriptive name. 
   💡This name is just for Nimbus UI purposes.
3. Define the Organization Unit under which this Bot will be selectable. 
4. Type is Nimbus AI Service — Nimbus hosts the AI, no endpoint or API key required.
5. Agent Type is Azure OpenAI — the only agent technology available when Type is Nimbus AI Service.
   💡The Profile (which makes this bot an Intent Analyzer) is selected on the Virtual User in the next step, not on the Bot.
6. Save and Close.

Configuring the Virtual User

✅ Virtual Users. Here you can give your AI bot instructions on how to interact with the Customer.

1. Head to Nimbus Administration > Configuration > Virtual Users and create a new Virtual User.
2. Give your Virtual User a descriptive name, e.g. Virtual Front Desk Concierge.
   💡This name is just for Nimbus UI purposes, e.g. for later selection in your Workflows → Next step.
3. Define the Organization Unit under which this Virtual User is selectable. 
   💡Should ideally match your intended Services and Workflows accessing this Virtual User. Of course you can pick a “higher” OU if you want to share this definition among similar Services that will use the same kind of Agent for Customer interaction.
4. Select the Bot you configured above.
5. Set Profile to Intent Analyzer.
   💡The Profile decides how the bot behaves in the conversation. Intent Analyzer runs on Nimbus' pre-defined intent-classification prompt — choose this for the use case described here.
   💡Existing Virtual Users were migrated automatically: bots that were previously of type Nimbus AI Services - Audio Intent Analyzer now have Type = Nimbus AI Service and their Virtual Users carry Profile = Intent Analyzer. No manual action is required.
6. The “System Instructions” acts as a behavioral guideline for your Virtual User.
   

   A possible example of a System Instruction could be:

   You are a Front Desk Operator of an insurance company. If available, greet the Customer with their Client ID and $(CustomContextParameters.DOC_ClientId) Company $(Customer.Company). Politely ask for their reasons for calling.

   💡Of course your flows using these parameters need to ensure that these Parameters have Defaults or a fallback in your data-retrieving Power Automate Flow Actions, so the Virtual User can operate normally when no additional data is available.
   
   💡Extension Tools (Web Requests / MCP Servers) are intentionally hidden for the Intent Analyzer profile. Intent classification runs on Nimbus' built-in prompt and is not allowed to call external tools — if you need that, pick the AI Workflow or Open Profile use cases instead. The AI Workflow and Open Profile options are covered in the related Use Case - Integrating Nimbus Virtual User with external systems.

    
7. Define the “Initial Message” of your Virtual User. 
   💡This is optional: The underlying AI will engage with the Customer automatically. Optionally you can add Custom Parameters or System Fields and Parameters (retrieved via CRM using Flow Actions) for a more direct conversation. 
8. Optionally you can also define a “Closing Message” – a short line the Virtual User will say before handing off or disconnecting (e.g. “Thank you, I'll transfer you to a colleague now.”).
9. Define the Voice & Language of your Virtual User.
   💡Nimbus development aims to expand this list of supported languages gradually, ensuring that every User Voice is also compatible with each Language selected. As this list is subject to change, please check the Virtual Users page for any announcements and potential phase outs.
10. If you want to use your Virtual User productively, ensure your Virtual User has a license applied. This license can either be applied directly in the Virtual User configuration steps below or - in bulk - via Admin > Licensing view. 
    ⮑ Applying the license enables usage of the “Add Virtual User” Workflow Activity.

Step 2 - Preparing your Parameters

✅During the live conversation with the customer, the Virtual User will use Parameters to fill in customer responses. As you configure the workflow further below, you will need to specify 3 parameters for the “Add Virtual User” Conversation Handling activity: 

• One “Fallback Parameter” which will be used by the AI if the customer request cannot be fulfilled. For example, if your bot is supposed to decide between “Sales” and “Support”, but the customer has a different question or problem to discuss, this parameter will contain the topic the AI identified as “Fallback”.
• Optionally: Two Parameters per Workflow “Add Virtual User” activity exit. 
  ☝Note that these parameters require “Virtual User Context” to be provided with the Parameter definition itself. Any information that helps the AI to fill in the correct information can be filled in.
  
  ✅If you want to handle more exits with corresponding data (e.g. Sales, Support), add more parameters and Virtual User Context as needed.

Step 3 - Configuring your Nimbus Workflow

✅Last but not least you need to configure a new Workflows to handle the Audio/Video interaction between Customers and your new Virtual User.

1. Head to Nimbus Administration > Configuration > Workflows.
2. Design or adjust any existing workflows you want to repurpose. 
   💡We recommend creating a copy of an existing Workflow so you can switch and test it with ease and return back should something not work as intended.
3. In your Workflow, Accept a call as normally. 
   💡Important: Do NOT add a “Queue” activity unless you want to involve human interaction in your workflow as well (e.g. after the Virtual User interaction).
4. Instead, connect your Caller to the AI by using the “Add Virtual User” in your workflow. You can find it in the Conversation Handling Activities. 
5. Configure the “Add Virtual User” activity as follows:
   1. Virtual User: Select from your list of Virtual Users as previously configured above.
      💡Note that the Virtual User will greet the Customer with the “Initial Message” field instructions provided. If any Parameters have been retrieved, they will be part of that message as well.
      💡Outbound calls - Good to know: when the “Add Virtual User” activity runs inside an outbound-call workflow, the Initial Message is spoken once the call connects — no extra silence before the greeting.
   2. Max Input Timeout: Define this to a reasonable time where no answer has been given by the Customer - e.g. 1 minute. → The activity will take the “Idle Timeout” exit.
   3. Define a Fallback Parameter which is used as the topic for the Virtual User if no resolution can be found.
      💡A good way to route this exit would be a regular “Queue” step, so a human can take the call instead of the Virtual User. 
      💡The Parameter can also be shown in the Extensions Service Settings (e.g. within My Sessions) as additional context for the receiving service user.
6. Optionally: Add additional activity Exits taken within your Workflow. An Exit is defined as follows: 
   1. Name of the exit, as shown in the activity bottom.
   2. Context for the AI on when to take this exit. These can be instructions like: 
      “The customer mentions an invoice, billing or other payment-related issue.”
   3. Up to two Parameters, as previously configured → in the chapter above.
      💡Note: When a parameter lacks “Virtual User Context” it will be shown with a warning. You may still select it, but the Virtual User will most-likely not know what part of the customer answer to fill into this parameter, so it will remain at its default value.
      
   4. Optionally: Add additional Exits and respective parameters as needed.
7. Finally: 
   1. Don't forget to route your all your Activity exits, e.g. Failed/Idle Timeout conditions.
   2. Establish a fallback route to Service Queues, Voicemail or Transfer where necessary.
   3. Don't forget the “Disconnect” activity at the end and to Save your workflow.

Known Limitations