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.
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.
Trigger and Workflow Correlation
💡 With the connector, you can leverage these Trigger events and react to Workflow Activities. The diagram below showcases how these events occur in a typical “Inbound Audio/Video workflow case, but technically this works with any type of workflow and modality.
☝ 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.
→ Nimbus Workflows allow usage of a Wait for Parameter activity which specifically waits for changes in your Parameters (e.g. while still being updated via Flow Actions).
→ We strongly recommend making test calls and plan for monitoring periods to check your flow performance, especially on large customer volume scenarios.
List of Trigger Events
When a task changes state
When a task changes 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 |
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”, |
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. Also returns UserSessionId and UserSessionStartedWithTransfer1. |
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). Also applies when the caller gets transferred to another service. Also returns UserSessionId and UserSessionStartedWithTransfer1 if LastConnectedUserId is set. |
“Disconnect” | Terminated |
| Outbound ↗ | None |
1 UserSessionStartedWithTransfer is set to true when the user session has been started as a result of transfer to user, and to false when the user session has been created not as a result of transfer.
🔎Related Pages:
- 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.
- A Call on Behalf started via the Nimbus API or the Flow Action "Start a call on behalf" raises the same task events as any other Call on Behalf. The events carry the Reference ID from the request together with the Call Chain ID, so a flow can match the call to the record it was started from (e.g. in a CRM).
- 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
🔎NOTES
-
☝ Certified and Custom Connector differences:
- All Roles listed in the table below have equal access rights to the Nimbus Power Automate Connector, however with varying detail Execution rights.
- Note that your installed legacy & Custom Connectors may still work using these roles, but will not receive access to new features, e.g. new Triggers and Actions.
→ ✅Tenant Administrator: If you still use a manually installed or legacy connector on your tenant consider a Connector Migration and adjust the roles accordingly.
-
☝Role enforcement on flow execution:
- Starting February 2026 Nimbus will enforce improved security, ensuring that Flow Actions are only triggered by users with valid permissions.
- The role will be validated at each execution of a flow.
- Effectively this means that if you change roles or Organization Units on users that wouldn't allow access to the corresponding Nimbus data anymore, the flows will also fail.
→ ✅Tenant Administrator: If you delegate running flows to Team or Service owners, ensure that any changes to their Nimbus Organization Unit are not revoking access to services that still require the flows. To minimize interruptions, we recommend to regularly review and confirm flow configurations and all involved user accounts to avoid any disruption or loss of data.
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 Get all scheduler entries GetOutboundTasks E E Update a scheduler entry - E E Remove a scheduler entry RemoveOutboundTask E E -
☝ Certified and Custom Connector differences:
When a scheduler entry changes state
When a 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 |
Related Info: Outbound Tasks
- 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.
- Scheduler entries on Direct Call Handling services raise the same events as on any other Service.
When the Companion has an update
When the companion has an update
⌛Legacy Trigger title: "When the virtual user assistant has an update”. The newer title is reflected when you install the latest Custom Connector. Other than the naming, the intended functionality is the same.
This event is related to the Voice Transcription feature and related Companion Service Settings. Triggers right after a user-customer session transcript is saved after a finished conversation.
Preconditions
- Companion requires Transcription to be enabled in the respective service's Companion Service Settings.
- The use of this feature requires prior setup. Refer to Use Case - Setting Up Transcription
| Companion Event | Description |
|---|---|
| Transcription Summarization Ready |
From selected “Service” parameter: Triggered when Nimbus Companion has been active during the session and reaches “Transcription Summarization Ready” event. Raised each time when a Summarization is stored after a user-customer transcription summary is saved after their conversation finishes. Task data sent:
Known Limitation: |
| Voice Transcription Ready |
From selected “Service” parameter: Triggered when Nimbus Companion has been active during the session and reaches “when the call ends” event. Task data sent:
|
Transcription Data Handover - Considerations1 The Companion events are fired whenever a transcription / summarization is ready for a user session, e.g. when the call is ended or after a Transfer from User A to Service B or individual User C. Therefore it is possible to have multiple “VoiceTranscriptionReady” events fired for a single service session. 💡Tip: You can listen to individual ✅ Related Action: You can follow up this trigger with the Flow Action “Get companion task data” e.g. to store the data into a Teams Message or Email. Refer to Use Case - Analyzing a Transcript to see an example. | |
When a Virtual User has an update
When a Virtual User has an update
This trigger relates to Transcription for Virtual Users. A Virtual User (GPT Realtime bot) generates a transcript of each conversational session. When Virtual User Transcription is enabled and the customer has consented, the transcript is finalized after the session ends and can be picked up in Power Automate for downstream workflows (e.g. CRM updates, quality assurance, case creation, complaint routing, or booking).
In addition to the raw transcript, the trigger also covers Summarization. When enabled for the service, Nimbus generates a short, structured recap of each Virtual User session once the session has ended, and raises a dedicated event for it. This lets a flow act on a brief, summarized outcome of the conversation without having to parse the full transcript.
✅ Preconditions
- Tenant Settings: This feature requires Tenant Admin consent on the Data Privacy Tenant Settings to enable the use of AI-assisted features.
-
Workflow Setup:
- A Virtual User1 must be set up (preconditions met) and part of the workflow.
-
Customer transcription consent is required, captured via the Record Consent workflow element (default is “consent granted”).
☝ If consent is explicitly denied with this activity, no transcript is generated, stored, or sent — and no trigger event fires.
-
Service Setup: Service Settings → AI → Virtual Users (Active toggles)
- Transcription must be enabled.
-
Summarization can be enabled optionally.
☝ Summarization depends on Transcription to be enabled. - Data Retention: The individual Store toggles control retention (1 hour or 30 days) for each feature.
1 Not supported for Virtual Users using Copilot / Direct Line 3.0 Bot integration.
| Virtual User Event | Description |
|---|---|
| Virtual User Transcription Ready1 |
From selected “Service” parameter: Triggered immediately after a single Virtual User session ends and its transcription is ready. Because it fires per Virtual User, you can receive a transcript for each Virtual User that was active within the same service session (e.g. one event per Virtual User). Task data sent (IDs only):
☝ The Transcription itself is not part of the event payload. Retrieve it with the Flow Action “Get Virtual User Data” using |
| Virtual User Transcription Summarization Ready1 |
From selected “Service” parameter: Triggered immediately after a single Virtual User session ends and its summary has been generated. Because it fires per Virtual User, you receive one event for each Virtual User that was active within the same service session. 💡 Use this event when you want to react per Virtual User — for example to open a CRM case as soon as the first, intent-detecting Virtual User has finished, without waiting for the whole service session to end. Task data sent (IDs only):
☝ The summary itself is not part of the event payload. Retrieve it with the Flow Action “Get Virtual User Data” using |
| Service Session Terminated |
Triggered once the overall service session ends. Use this event to retrieve all Virtual User transcriptions of that service session at once — instead of reacting to one Virtual User Transcription Ready event per Virtual User. 💡 When Summarization is enabled: all Virtual User summaries of that service session are ready by the time this event fires — so a single flow run can collect every transcript and every summary at once, instead of handling one event per Virtual User. Task data sent (IDs only): same IDs as above. |
Transcription Data Handover - Considerations1 The Virtual User events are fired whenever a transcription / summarization is ready for a user session, e.g. when the call is ended or after a Transfer from Virtual User A to Service B or individual Virtual User C. Therefore it is possible to have multiple “VirtualUserTranscriptionReady” events fired for a single service session. 2 ☝️ Note: The event payload contains IDs only. To retrieve the actual transcript, use the Flow Action “Get Virtual User Data”:
| |
When a voicemail is ready
When a voicemail is ready
Preconditions
- A “Voicemail” Conversation Handling Activity must be part of the service's workflow.
- The service's “Voicemail Transcription” setting in Modalities Service Settings is optional — it is not a precondition for this trigger to fire. If enabled, the payload additionally carries the transcript once transcription completes; if disabled (or if transcription fails), the trigger still fires with an audio-only payload.
This trigger fires when a Voicemails recording is available in a Nimbus service. A voicemail is a recording produced after the caller leaves a message and hangs up. It fires exactly once per voicemail, whether or not the voicemail is transcribed.
The trigger fires whether or not the voicemail is transcribed:
- Transcription off — fires as soon as the recording is ready (audio-only; Transcribed = false, no transcript).
- Transcription on — fires when the transcription completes; the payload then carries the transcript (Transcribed = true).
| Voicemail Event | Description |
|---|---|
| Voicemail Ready |
From selected “Service” parameter: Triggered once per voicemail, as soon as the recording (and, if enabled, its transcription) is ready. Task data sent (always):
Task data sent (only when
|
🔎Notes
- Whether the payload carries a transcript does not affect whether the trigger fires. A failed transcription still fires the trigger (audio-only).
- The voicemail must originate from a Nimbus session (a resolvable
servicesession); recordings without one are skipped. - Use the
CallIdandRecordingIdfrom this payload with the Flow Action > “Download recording ” (Located in the Voicemails & Recordings tab) to retrieve the voicemail's audio file in the same flow.
General Notes
Migrating from Custom-Installed Connectors
The following applies when you got Trigger Events shown from a previously installed Custom Connector and want to migrate to the official Connector from the Microsoft Store instead.