Trigger Events

How Nimbus Trigger Events in Power Automate correlate to Workflows

Nimbus treats all incoming calls, chat requests, and other modalities as Tasks. The Power Automate connector primarily listens to Events related to changes in a task's status.

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!

  • Has full access to all Organization Units and their underlying Nimbus data entities.
  • Can see all tasks of service teams on the tenant.
  • Can use Trigger Events for all services on the tenant.
  • Can use flow actions as follow-up on trigger events, e.g. access Address Books / update tasks.
Team / Service Owner

☝ Usable, but limited access to data entities within Organization Unit rules of user account (reading up the path rule):

  • Can use triggers for assigned service teams only.
  • Can see all tasks of service teams only when part of the "Owner" group in MS Teams or where manually assigned as Service Owner.
  • No permissions to access or update connected Address Books .
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.

 
 
 

During an active task, Nimbus will send trigger events according to the steps configured in the respective service Workflow. These Events can then be followed up upon using Flow Actions. All triggers are available for selection within the Power Automate Connector and described in the following.

💡 With the connector, you can leverage these events and react to activities in your Nimbus service Workflows. The diagram at the right showcases when such Trigger Events occur during a inbound call workflow.

Example Workflow with related Trigger Events

INC Power Automate Connector Deprecation Notice

☝ Deprecation notice: With the new (store-certified) Nimbus Power Automate Connector there are changes on Flow Actions, Triggers as well as Field and Event descriptors which require a Connector Migration.

✅ If you are using a deprecated (manually installed) connector you should perform a Connector Migration as soon as possible.

Learn more…

🤔 Why are contents on the Knowledge Base still showing old connector info? As Microsoft still changes the design / naming on Power Automate rather frequently and without notice, we shift our approach to be more “In-App” centric. This means that future connector updates will include guidance and in-app help as far as the Flow UI allows. Legacy Connector Knowledge Base contents will remain online for future reference, e.g. to perform a Connector Migration and comparison.

🤔 Why is the new verified Connector still shown as “Preview”? The Luware Nimbus certified connector and related Flow Actions are ready for productive use. Microsoft will remove this tag once the connector has seen frequent use on Microsoft official clusters, primarily after meeting their “General Availability” criteria.

🤔Why is Use Case XY is not covered in the new Connector (yet)? Our Knowledge Base will gradually move existing Power Automate Use Cases over to the new certified connector. If you require assistance on our existing Power Automate Use Cases, first check the Connector Migration page for hints. You can also contact Customer Success to request updates to Knowledge Base pages.

 
 
 

☝ Please Note: Trigger event reaction times rely on Microsoft Power Automate and Azure infrastructure.  Account for delays (e.g. with announcement workflow activities while connecting to external systems) or while relying on user input, as each action in your flow can cause additional delays. 

Workflows also allow for a Wait for Parameter activity which specifically waits for changes in your Parameters (e.g. updated by a flow).

→ Either way: We strongly recommend making test calls and plan for monitoring periods to check your Flow performance in large call / task volume scenarios.

 

Trigger: When a task change state

This trigger is raised “When a Nimbus task changes state”. The table below describes the different event details:

Task Events Supported Modality Direction Description

Related Workflow Activities          
(either modality)

Legacy Connector “Session” Event (deprecated)
Workflow Started Inbound ↙

Triggered during an incoming task to a service line.

☝ Will only be triggered once for the initial incoming task arriving at the first service.

None, right after the "Start" node in a workflow.        
 
Created
Outbound ↗ Triggered when outbound service task is started. None
System Accepted Inbound ↙ Triggered when incoming task was accepted by the service. "Accept" Accepted by System
Parameter Updated Inbound ↙ Triggered whenever a parameter is set or updated by a Workflow Activity.

"Collect Information",

"Save to Parameter",

"Get Available Users",

“Get Queue Position”,        
"Input Customer Advanced"

Parameter Updated
In Queue Inbound ↙ Triggered when the task was put into the queue.

"Queue",

"Queue Task"

Queued
Outbound ↗ None
Connected to User Inbound ↙ Triggered when the task was connected to a user. As part of:        
"Queue",          
"Queue Task"
Connected to User
Outbound ↗ None
Destination Reached Outbound ↗

Triggered when connected to the destination.

💡Applies to Outbound Calls and Call On Behalf.

None Outbound Connected to Destination
Queue Left Inbound ↙ Triggered once the task leaves the queue (either when the caller left while waiting in the queue or when the maximum queue timeout was reached). During or right after:        
"Queue"
Queue Left
Outbound ↗ None
Terminated Inbound ↙

Triggered once the task is terminated (caller left, Nimbus user left, or task was cancelled by the workflow).

"Disconnect" Terminated
Outbound ↗ None
  • Each Trigger Event can update System Fields and Parameters which are available as data fields within the Nimbus Power Automate Connector and the Nimbus UI itself.
  • You can follow Triggers with additional Flow Actions, e.g. to manipulate entries in Nimbus-internal Address Books, or change task details.
  • Of course, you can combine any Trigger Event or Flow Action with your own flow actions, e.g. reading info from external directories, triggering a MS Teams message, etc. Refer to Power Automate Use Cases for more inspiration.
  • The User Role (RBAC) Matrix determines which Nimbus Services and related Triggers / Actions are available to the user.

    Roles with Power Automate Access

    Power Automate Roles

    Revoked Role Limitation

    🔎 Roles described table below have access to the Nimbus Power Automate Connector

    ☝If a User configures a Power Automate Flow for a service, but then loses permissions to configure such a flow (e.g. removed as Service Owner), the previously configured Power Automate Flows will still be triggered.

    ✅When changing service ownership we recommend you to check for leftover flows or use a global administrator to manage all your flow needs in a centralized fashion.

     

    Table: Nimbus Power Automate Permissions

    🔎Legend: Create, Read, Update, Delete, Execute

      Certified Connector Custom Connector Tenant Admin OU Admin Team/Service Owner Team Owner Limited
    Conversations Triggers - GetOnNewTasks E   E  
    When a task changes state GetOnUpdatedTasks E   E  
    When the virtual task assistant has an update   E   E  
    Actions Update task UpdateTask E   E  
    Add a new external task AddExternalTask E   E  
    Remove an external task RemoveExternalTask E   E  
    Get Data from Virtual Task Assistant   E   E  
    Address Books Actions Add a contact to an address book AddOrUpdateContact E E    
    Update a contact in an address book - E E    
    Empty an address book ClearContacts E E    
    Get contact(s) from ana address book GetContacts E E    
    Remove contact(s) from an address book RemoveContacts E E    
    Outbound Service Calls Triggers When a scheduler entry changes state GetOnUpdatedOutboundTask E   E  
    Actions Schedule a new outbound call AddOrUpdateOutboundTask E   E E
    Get all scheduler entries GetOutboundTasks E   E  
    Update a scheduler entry - E   E  
    Remove a scheduler entry RemoveOutboundTask E   E  
     
     
 

Trigger: Scheduler entry changes state

Scheduler Entry Events are used as wrapper for Outbound Calls to cover the lifecycle before the outbound call becomes a task (queued and looking for a Nimbus user).

Scheduler Entry Events Description Legacy Connector “Session” Events (deprecated)
Scheduled Triggers when outbound task gets successfully scheduled or new attempt is re-scheduled. Scheduled
Due date reached Triggers when distribution attempt is started (queued and looking for a Nimbus user). InProgress
Handled Triggers when outbound task completes after destination (customer) is reached. DestinationAccepted
Limit reached Triggers when the maximum amount of retries for the outbound task has been reached (all attempts were unsuccessful). MaxRetriesReached
Removed Triggers when a supervisor manually removes the task from the Personal Dashboards via Outbound Tasks-type Widgets, or if the task is removed via Power Automate action. Removed
Failed Triggers when task either fails by system error or when e.g., killed by admins in the backend. Failed
  • Certain Flow Actions (e.g. Schedule a new Outbound Call, Get all scheduler entries, Update a scheduler entry, Remove a scheduler entry) can create, remove, and manipulate outbound task properties such as: Retry Count, Target Service, Priority, etc. Note that this overrides the defaults specified in the respective Workflows.
  • During a Scheduler Entry Event System Fields and (custom) Parameters can be updated e.g. by using “Update a scheduler entry” or other Flow Actions and made visible in the My Sessions → Session Details widget. The actual parameters shown to users can be configured via Extension Service Settings.
 

Trigger: When the virtual user assistant has an update

This event is related to the Voice Transcription feature and triggers right after a user-customer transcription is saved after a finished conversation.

Preconditions

 

INC Azure Billing Transcription

AZURE BILLING

The usage of the Transcription feature will cause additional monthly ACS costs. The costs are determined by Microsoft. Also see https://azure.microsoft.com/en-us/pricing/details/cognitive-services/speech-services/.

  • Before enabling the Transcription feature, get in touch with your Luware Customer Success specialist to discuss terms, usage scenarios and necessary setup procedures.
  • Please note that Nimbus and Transcription support does not cover pricing discussions or make recommendations based on Microsoft Azure infrastructure.
 
Scheduler Entry Event Description
Voice Transcription Ready

From selected “Service” parameter:

Triggered when the Nimbus User Virtual Assistant has been active during the session and reaches “when the call ends” event.

 

Event Data sent is:

  • ServiceSessionId
  • TenantId
  • ServiceUPN
  • ServiceId
  • ServiceName

🔎 Related Action: You can follow up this trigger with the Flow Action “Get Data from Virtual User Assistant” e.g. to store the data into a Teams Message or Email. Refer to Use Case - Analyzing a Transcript to see an example.

 

Table of Contents