INC Power Automate Preconditions
PRECONDITIONS
☝External licensing costs
A Microsoft Power Automate subscription with "Premium Tier" license is required to set up the necessary connectors in your Flows. Note that the pricing for these accounts is determined by Microsoft and outside of your Luware subscription.
☝Nimbus Licensing
Licensing: To use the Power Automate integration, at least one of your Nimbus services must be Enterprise Routing or Contact Center licensed. Additional licenses can be assigned via License Management in the Administration UI.
Configuration: Flow interaction requires an existing Nimbus service already provisioned on your tenant. Power Automate Trigger Events react to Workflow Activities in your currently running Nimbus Workflows – as defined in your Modality Service Settings. If your service has no (valid) workflow defined, trigger events will not be recognized.
☝User Roles
You need either Team Owner or Administrator in Nimbus to set up Power Automate Flows. Check that your currently logged-in user account has one of the required Nimbus Power Automate Roles.
💡Tip: To keep impacts and licensing cost to a minimum we recommend setting up flows as a Tenant Administrator as you have full access to all services and their configuration items located within their respective Organization Units. This also reduces the risk that Flow Actions and related Trigger Events suddenly stop working, as Nimbus Configuration entities, permissions or related user roles change.
Learn more about this…
The same user account UPN you use in Microsoft Flow is matched with the according User Role granted via Nimbus User Administration. Nimbus data is filtered via the Organization Unit placement of your logged-in user account. In effect, Services and Users outside of this OU placement are (not) shown in Flow Actions and Trigger Events to prevent accidental manipulation.
The following table will give you a brief overview on which Nimbus User Role can manage Power Automate flows:
| Nimbus User Role | Notes on Flow access |
|---|---|
| Partner Admin | ❌ Cannot use triggers for services in the customer tenant with his own account. Also have limited visibility on live-data. |
| OU Admin |
☝ Can access the connector, but is not recommended to manage live call-data with, as the view on services and user data is restricted by Organization Units. If the Admin role is moved or deprecated, flows may cease to function correctly.
💡This role is primarily meant for assisting on configuration tasks, e.g. managing flow-related Address Books and Workflows. |
| Tenant Admin |
✅ Recommended!
|
| Team / Service Owner |
☝ Usable, but limited access to data entities within Organization Unit rules of user account (reading up the path rule):
|
| Supervisor / User | ❌ Have no access to the connector itself or any related configuration items and service settings. |
🔎 Refer to Power Automate Roles for more details.
INC Icon Legend Accordion
Show Icon Legend
| 💡 = A hint to signal learnings, improvements or useful information in context. | 🔍 = Info points out essential notes or related page in context. |
| ☝ = Notifies you about fallacies and tricky parts that help avoid problems. | 🤔 = Asks and answers common questions and troubleshooting points. |
| ❌ = Warns you of actions with irreversible / data-destructive consequence. | ✅ = Intructs you to perform a certain (prerequired) action to complete a related step. |
Nimbus in Power Automate
Via Power Automate you can leverage the Nimbus Power Automate Connector to create cloud workflows to integrate into any external system. This happens in four basic steps:
- In Power Automate you generally start flows on triggers, such as inbound and outbound tasks of Nimbus.
- As soon as the task is accepted by Nimbus for distribution, Power Automate receives a Trigger Event sent by Nimbus .
- A simple example flow consists of connecting to your external system (CRM, Ticketing System, Address book, SharePoint list etc…) followed with an update of the Nimbus Task using the retrieved data.
- Nimbus then updates all it's front UI screens (e.g. My Sessions or Attendant Console to show the data.
💡 Many more Use Cases with similar examples can be found at the bottom of this page.
Example Flow
In this flow we're going to apply the concept described above, by reacting to an inbound call (1). When accepting the task a trigger event starts the flow (2). A Flow Actions will now retrieve customer information from an excel sheet (3) to eventually show the data in the My Sessions view (4) of Nimbus.
Step-by-step - Building your first Nimbus Flow
✅ You can follow these steps below to design your flow. You can download and use the example Excel sheet to quickly test your flow and see how the data is shown in Nimbus. Once your flow is successfully set up with the excel data, you can easily swap the excel connector with a connector to your external system.
| Step | Screenshot |
|---|---|
|
This is the flow overview. As you can see it consists of:
|
 |
|
Login to Power Automate.
Start a new “Automated Cloud Flow” and search the Luware Nimbus Connector from the Premium Connectors list which is accessible directly within Power Automate.
Select the Trigger Events "When a task changes state". |
 |
|
Click the trigger element “When a task changes state” and select your Nimbus cluster. This only needs to be done once.
Once a connection with a specific user is established it is saved in the power automate environment and will automatically be reused for additional flows using the same connector.
💡Tip: You can always change the connection picked on the next step.
Once the location is selected, you are requested to sign in to Nimbus using either your Service Owner, Service Supervisor or Admin account.
🔎 Also see Power Automate Roles for details.
|
 |
|
Once signed in, you see the task configuration.
💡Note: The selection of services depends on the Organization Unit and permissions of your signed in user account. You can always change the connection picked from the previous step on the bottom of this tab. |
 |
|
Now select the service name you want to listen to. 💡 You can also select more than one service.
Filter on Task event “System Accepted”. This is your Trigger Event that relates to the Nimbus Workflow handling your task.
✅ As this example is meant to catch inbound calls via telephone (audio), you need to filter the Modalities item to “Audio” and Direction to “Inbound”.
☝ If these modality filters are not set, the Flow would trigger unnecessarily often, e.g. on an incoming Mail or |
 |
|
💡 We now use the Excel connector to access a file called “Addressbook.xls” which is shared on a MS Teams channel.
✅ You can download and use the example Excel sheet as a baseline.
In this example you can select the table area and filter the column named “MobilePhone” by phone number which comes predefined as Customer Identifier System Field of the Nimbus task.
|
 |
|
💡Now we can update the Nimbus task using the Task ID from the trigger and the fields which have been retrieved from the excel list.
✅ Have a look in the example Excel sheet headers to determine which field needs to be placed in the Flow action.
Useful to know:Nimbus tracks a lot of default “System” parameters with their own fields. Visit System Fields and Parameters for a full overview. Note:Any input contents for Nimbus context (coming from external systems) must be of "plain text" type – or converted accordingly. Other forms of media are currently not supported.
|
 |
|
✅ Make a test call to your service (there is a button in General Service Settings) to test if the trigger events are recognized.
💡Note: You can also adjust the fields shown in your service via Extensions Service Settings. |
Expected result: When the call is now accepted by an user in Nimbus, the user sees all the Information of the caller in the My Overview “My Queue”, Live View, on the My Sessions page and in Nimbus Assistant. |
Improving your flow
In this basic example flow, we did not consider internal/external calls or different modalities. Here are some examples to help achieve a more sophisticated version of your flow.
Filter out Anonymous callers
You can filter external anonymous callers hiding their phone number using a Condition element in your flow just before handling the Audio modality.
Distinguish between internal and external teams calls
You may want to distinguish between internal and external calls within the Audio modality. For external calls, the Customer Identifier contains a well-formatted PSTN number, for internal Teams-to-Teams calls the identifier consists of an Office GUID while the field Customer UPN would contain the email.
🔎 Read how to set this up in Use Case - Distinguishing External from Internal Calls.
Add more modalities
You can either create distinct flows for distinct modalities or add all other modalities to one flow. You need to introduce a switch on the modality and handle each modality distinctively because there are some differences in the modalities.
- Chat identifies with the customer email which was given to the system when the customer starts a new chat session on a web site.
- Email identifies with the customer email
- External Task identifies with a Task Id from your external task system
Each branch of the switch can contain a call to your data (i.e. Excel) and update the nimbus task.
Additional Notes
GOOD TO KNOW
- You may also access, update and manipulate connected Address Books using the dedicated Nimbus “Address Book” Flow Actions steps. Please note that this may also affect Attendant Console users when accessing the same Address books in their search.
- Note that Nimbus will not wait for Flows to complete, nor request any updates by itself as it may impact call performance. If a flow is not working as intended, the call context in a Nimbus task is simply not updated.
- Feel free to experiment with advanced IF/THEN switch conditions and error-handling loops in your flows. ☝ However, keep the overall flow runtime in mind.→ See next point.
- Keep in mind that context takes at least 1-2s for each Flow to update, which might delay information gathering during huge call volumes. Use the "Flow Checker" history to review performance during peak hours and consider shortening your flows if necessary.
- When creating Flows that intend to inform your team via Teams Message or Email, consider enabling Adaptive Cards support in a "Queue" Workflow Activity. Adaptive Cards may also show context if provided by a Flow.
- Find more inspiration in our Power Automate Use Case category.
INC Use Case Support Disclaimer
LIMITED SUPPORT ON USE CASE SCENARIOS
Use Case contents listed on this page have been created as examples.
🤔 What does this mean?
- Our documentation was created within the versions of 3rd party products (e.g. Salesforce, Zendesk or other vendors) available to us. Your personal version or licensing type of 3rd party products may vary and change over time, resulting in limited or missing functionality.
- Luware and Nimbus Support cannot guarantee that the example scenarios will work in every (future) customer scenario. Please consult your 3rd party manufacturer to determine whether your product version supports the functions and interfaces mentioned in our Use Cases.
- Luware and Nimbus Support does not cover integration setup and administrative scenarios with any external systems mentioned in the documentation (e.g. Salesforce, Zendesk, Microsoft Dynamics, and other 3rd party manufacturers).
- Luware does not provide support nor guarantee the executability of Use Cases in your environment.
→ Please ensure that you run your own internal testing before rolling out any large-scale integration into productive systems.
→ If you need further support for your Nimbus integration, please reach out to your account manager or customer success specialist.
🤔 On which topics can I get support on?
- Troubleshooting on the Nimbus Power Automate Connector.
- Troubleshooting on retrieval/integration for Nimbus System Fields and Parameters.
- Inquiries on improvements and requests for Nimbus Features.
- Any Feedback on our documentation (e.g. corrections and updates)