This page will always reflect the latest Release Notes, recent improvements and changes made to Nimbus.
Other Information Resources:
- Our Release Note History contains information on all previous releases from this year.
- Updates on our Nimbus Power BI Template are distributed on request. Please refer to the Nimbus BI Template Release Notes for updates.
- To stay up to date on Nimbus feature and upcoming maintenance, please visit the following resources:
INC External News Resources
š£Important Announcements
Please take note of the following long-term and ongoing announcements below:
INC OData Server-driven pagination
OData Server-driven pagination
Starting February 2026 the Nimbus OData API handles large dataset requests with pagination using @odata.nextLink. Paginated results with a maximum of 100'000 entities per response are enforced.
Impacts to customers may not be obvious (non breaking change), but if the interface consuming the OData is not ready to handle pagination, partial results may be āsilently" shown.Ā
ā Actions required:Ā
-
If you are using the Nimbus Power BI Template version 1.122 or above, you can expect it to handle
@odata.nextLinkout of box.Ā
ā Unless your template has been modified, there is no need to take action. In principle, older templates should also handle this automatically, however in case of problems, we recommend to always check if you can reproduce the issue with the most recent template listed in the Nimbus BI Template Release Notes. - In case you need to refresh and view large sets of data regularly, we still recommend looking into setting up Incremental Refresh using Power BI Online services. This will automate and schedule the refresh procedures, decreasing the amount of data loaded for each ongoing time increment.
- When using custom or 3rd-party solutions to consume OData you must familiarize yourself with the specifics of the tools and interfaces you use to ingest data from our OData API.
š¤What is @odata.nextLink?
š@Odata.nextLink isā¦:
- ā¦ a property used in OData responses to support pagination. Its presence indicates that the response is larger than what can be fit in a single response.Ā
- ā¦ an indication that there are more results to be fetched, before the request is fully satisfied.
- ā¦ URL that can be used to call and retrieve the next page of results. The URL is server-generated (never modify it).
- ā¦ an OData standard. Typically returned by OData services including Nimbus, Microsoft Graph, and any OData v4-compliant API.
- ā¦ essential for consuming large datasets.
- ā¦ handled out of the box by most mainstream data platforms that claim native OData ingestion support and have native OData connectors (e.g. Power BI, Excel, Azure Data Factory, etc.).
šThings to be aware of:Ā
- A system that sources data from the OData relying on a non-paged behavior may quietly end up with partial query results.Ā
- Systems that rely on custom logic to extract OData may not handle pagination automatically and may need manual intervention to handle it. E.g.:Ā
- Raw HTTP clients (curl, Postman, custom scripts)
- Generic REST connectors without OData awareness
- Older OData v2-only connectors (some legacy tools)
- 10,000 is the maximum set ā not a guarantee. Some pages may contain fewer records.
š @odata.nextLink works as follows:
- The data client generates a request to the OData service.
- The OData service responds.
- The presence of
@odata.nextLinkin the response indicates that the server has more data available. - Clients must continue issuing requests using the provided URL until no
@odata.nextLinkis returned.
š¤How does it work in the BI Template?
š”Good to know: The default official Nimbus Power BI Template does not need to be updated in order to handle the introduction of "@OData.nextLink". Power BI expects this behavior and handles it automatically.
āIf you customized the template, ensure that you are familiar with your code and how this could interfere with the standard @Odata.nextLink behavior. If unsure, update the default template to the newest version.
šHow does Odata.nextLink improve stability of the OData service with Power BI?
| ā With server paging Power BI | ā Without server paging Power BI |
|---|---|
|
|
š¤Which Nimbus data is affected?
Impacted OData entities from the Nimbus Reporting Model and Data Aggregation are as follows:Ā
ServiceSessionsAggregatesUserSessionsAggregatesUserStatesAggregatesServiceSessionsUserSessionsUnifiedSessionsTransferSessionsCallers
š¤Why does the data refresh take longer after this change?
šThere are two reasons to this:Ā
- Equal load distribution: OData pagination is a change that we have implemented to improve stability of the architecture, serving concurrent requests from multiple tenants simultaneously. This is to ensure a fair and equal load distribution of available server resources amongst all Nimbus customers.
- Consistent performance: Compared to the previous setup, OData pagination could in some cases make the refresh times appear inconsistent, even on an seemingly identical data scope. The reason ā particularly with very large datasets ā was that multiple sequential requests to retrieve all data were required.
Ā š”For these reason we recommend to implement Incremental Refresh and be mindful of the size of the query when hitting the OData Feed.
INC Application Consent Presence Service Notice
ā Admin Action Required: Migration to new Presence Service
š What it is about: The Nimbus presence service continuously tracks each agent's real-time MS Teams status (available, busy, in a call, or away), so Nimbus only routes customer calls to people who can actually take them. As of Today, Teams presence is polled from Microsoft Graph in three ways:
- Application permissions1Ā (current standard)
- FederationĀ (deprecated)
- Guest accounts Ā (deprecated)
āļø Why migration is needed: The main reason isn't a technical limitation; it's that Azure federation and guest-account polling are already deprecated. Luware development therefore rewrote the design, which is designed around application permissions.Ā
ā What Tenant Administrators need to do:
- If your tenant still runs or federation or guest accounts, a one-time admin step is required before you can switch.Ā
š”The legacy service keeps running until all Tenants are migrated. - As tenant admin you need to grant admin consent to the Nimbus application in your Microsoft tenant, a single approval in Entra/Azure AD.
Ā Ā a. We will provide you with a URL including your Tenant ID to click, authenticate and approve the consent.
Ā Ā b. As an alternative, you can re-run the Provisioning PowerShell script. - Once done and confirmed, we switch your Tenant to the new presence service.
š” Example of the consent link:
INC Nimbus ACS grant consent links
https://login.microsoftonline.com/<tenantId>/adminconsent?client_id=<Your cluster Application ID>š”Note: Running the Provisioning PowerShell script should cover missing consent needs. More details can be found on the Nimbus App Permissions page. If you require a specific ACS consent grant link for your Nimbus cluster location, please get in touch with Nimbus support.
End of announcements. Regular release notes continue below.
12 August 2026 - 1.133 Release Notes
š This is a major update, bringing many new changes and improvements into Nimbus. This update is being rolled out sequentially on our clusters:
| Cluster | Update on |
|---|---|
| United States 01 | 12/08/2026 |
| Australia 01 | 13/08/2026 |
| United Kingdom 01 | 18/08/2026 |
| Switzerland 02 | 20/08/2026 |
| Germany 02 | 20/08/2026 |
| Switzerland 01 | 23/08/2026 |
| Europe 01 | 26/08/2026 |
| Germany 01 | 30/08/2026 |
Historical Visibility for Deleted Services in OData/Power BI Reporting
Historical session data for deleted services is now accessible to more than just Tenant Administrators. Service Supervisors and other OU-scoped roles consuming reporting data via OData or Power BI now retain visibility of session data for deleted services, for as long as that data falls within the retention period ā without needing Tenant Admin access or manual workarounds.
š Added with this update:
- Historical
ServiceSessiondata for deleted services remains visible via OData/Power BI, provided the user has the appropriate OU permissions. - Access continues to be evaluated based on the OU the service belonged to at deletion time.
š” Good to know: Once a service is deleted, its permissions can no longer be changed ā visibility remains tied to whoever is responsible for that OU going forward. If the OU of a deleted service is also deleted, visibility of that service's historical data is limited to Tenant Administrators.
š Related KB Update: Reporting Roles updated with new footnote to explain the data access after service deletion.
Callback Routing via Workflow Activity
Customers no longer have to wait on hold or rely on Power Automate to get a callback. With the new Initiate Callback Queue Activity, organizations can offer callbacks directly from IVR menus, queue overflow paths, or business-hours conditions, keeping queues moving while giving customers a convenient way to be called back instead of waiting live.
| Scenario | Previously | With Callback Workflow Activity |
|---|---|---|
| Offering a callback | Required building and maintaining a separate Power Automate flow alongside the Nimbus workflow | A normal workflow activity, dropped directly into the call flow. No Power Automate flow required. |
| IVR menu option | Not natively available; required custom Power Automate logic to trigger | Add Callback as the destination of a menu option (e.g. "press 1 for a callback") |
| Queue overflow | Customers kept waiting once in queue, with no built-in way to offer an alternative | A queue/wait-time check can route directly to Callback once a threshold is reached |
| Outside business hours | Typically ended in an announcement or voicemail, with no way to schedule a return call | An opening-hours condition can route to Callback as an alternative to voicemail |
| Existing Power Automate callbacks | - | Continue to work unchanged; Callback is an additional, simpler option, not a replacement |
š Added with this update:
- A new Initiate Callback Queue Activity (available for Enterprise and Contact Center services), configurable with retry limits, retry timing, and an optional alternative target.
- Workflow-initiated Callbacks are Outbound Calls ā and as such integrated in the existing UI Experience:Ā
- They appear in My Overview, My Sessions, My Sessions and Attendant Console, showing live state (Queued / Ringing / Dialing Out / Connected) alongside customer identity and reference ID.
- Attendant Console: transfer and consultation actions are available for callback sessions.
- In flexible Personal Dashboards and Non-Personal Dashboards callbacks are represented in existing the existing Dashboard Widgets, e.g. within āLive Service Tasks Tabularā and āService Outbound Tasks Tabularā.
-
Nimbus Reporting Model > Static Dimensions: Ā A dedicated Callback task type and a new Callback Scheduled outcome have been added. Added Callback to tables Service Session Outcomes (
49) and Task Type (10)
Email: Configure target folder for Service / Shared Mailboxes
Service owners can now select a specific folder within Mailboxes as the subscription target for Email modality processing. This enables cleaner mail triage: rules can move relevant messages into a dedicated folder, and Nimbus picks up only from there. It also allows multiple services to draw from different folders of the same shared mailbox, giving Nimbus users more flexibility in how they structure and separate their email workflows.
š Added with this update:
- A new "Folder" dropdown in Modalities Service Settings to select which folder of the subscribed mailbox should be monitored. The picker only lists folders that actually exist in the mailbox, hides Nimbus-managed system folders (Handled/WF Ended/Failed) and other well-known folders (except Inbox), and flags folders already used by another service.
- A mailbox is no longer unique per service. Uniqueness is now based on the (Mailbox, Folder) pair, so one mailbox can now be shared across multiple services as long as each watches a different folder. The Admin mailboxes grid and workflow settings show and filter on the multiple services assigned to a mailbox.
š”Existing subscriptions default to the "Inbox" folder, ensuring no disruption for already configured Mailboxes in your Modalities Service Settings. - Changes to the Folder setting are tracked in Change History.
š”Note: The folder can only be selected once a subscription/permission to the underlying mailbox has been established. Subscriptions continue to be forward-facing only: switching a mailbox/folder assignment only picks up mail arriving after the change ā mail already sitting in the newly selected folder is not retroactively processed.
ā Getting started: If you are new to the feature or require a setup-refresher, refer to our Use Case - Setting Up Email.
Summarization for Virtual User
Getting the gist of a Virtual User conversation no longer means reading the full transcript. With the new Summarization for Virtual User feature, Nimbus automatically generates a summary for a Virtual User session, following the same structure already used elsewhere in Nimbus. Summaries can be retrieved via Power Automate for reporting, CRM updates, or downstream automation, right when they're ready, or once the service session ends.
INC Upcoming Connector Feature Certification
āPending Connector Certification: Features or functional changes described in the following are still undergoing a Microsoft review and certification process. Your Power Automate UI may differ until the changes are certified and rolled out for the latest official Nimbus Power Automate Connector.
Available Connector update paths
Connector Update Paths
As the connector certification by Microsoft is a continuous process, you can either opt to manually update to the latest ācustomā connector OR wait for automatic updates after certification:
INC Power Automate Connector Update Path
| Customer Tenant Admin Procedures |
Nimbus Customers can choose between following upgrade paths for the Power Automate connector:Ā
|
||||||||
| Luware Development |
Whenever Luware releases a Nimbus Version, the āUpcoming V1ā connector can be retrieved as a Luware-hosted download.Ā
|
||||||||
| Luware / Microsoft connector Certification Process |
The V1 download package is submitted to Microsoft for Store Certification.
š”Note: Each update triggers a re-certification process by Microsoft and takes ~4-6 weeks. |
Accessing the latest connector
When to test Connector functionality
Updating the Nimbus Custom Power Automate Connector
Luware development implements changes in the upcoming Nimbus Power Automate Connector (v1) and starts a certification process with Microsoft right after every major Nimbus release.
š¤When do I need to manually update a custom connector? If the official Nimbus Release Notes mention new connector features which you would like to try out ahead of time ā e.g. by adding new actions and triggers ā you can perform a manual update and install the V1 connector as Custom Connector on your Tenant.
Learn moreā¦
INC Power Automate Connector Update Path
| Customer Tenant Admin Procedures |
Nimbus Customers can choose between following upgrade paths for the Power Automate connector:Ā
|
||||||||
| Luware Development |
Whenever Luware releases a Nimbus Version, the āUpcoming V1ā connector can be retrieved as a Luware-hosted download.Ā
|
||||||||
| Luware / Microsoft connector Certification Process |
The V1 download package is submitted to Microsoft for Store Certification.
š”Note: Each update triggers a re-certification process by Microsoft and takes ~4-6 weeks. |
š”Good to know: Ā If you performed a Connector Migration before now use the Microsoft store-certified connector, you can skip the update steps shown below. After each V1 connector update re-certification by Microsoft, your connector updates automatically.
Manual Connector Update Steps
-
Retrieve the latest connector file from your Nimbus cluster region:
š” Uncertain? You can find out your region by logging into Nimbus Portal / Admin and see how the URL changes.
INC Nimbus Power Automate Connector URLs
āLegacy (v0)Ā Custom Connector users: Replace the /v1/ part of the URL above with /v0/ to download the legacy connector (e.g. to Update your existing Connector) with new files.Ā Note that the legacy connector will not receive feature updates anymore.
āMigration note for all custom-installed connectors: You can install the v1 to-be-certified connector as Custom Connector. However, when switching to the certified connector within Microsoft Power Automate, a Connector migration is necessary for all existing custom connectors.
- Go to https://make.powerautomate.com/ andĀ expand Data > Custom Connectors.
- Select your Nimbus Custom Connector from the list.
- Click on the Context menu (three dots) at the end of the line.Ā
- SelectĀ āUpdate from OpenAPI fileā.
- Click theĀ "Import"Ā buttonĀ and select the new file.
-
Finally clickĀ āContinueā.
ā® The connector is now updated and should be visible on your Tenant.
š Added with this update:
- AI Service Settings > Virtual Users: New Summarization toggle to enable the feature. Activates automated summary generation for every Virtual User session, stored based on the configured retention setting.
-
Power Automate Connector:
- Trigger Events: New trigger "When Virtual User has an update" with two selectable events: one that fires as soon as a single Virtual User's summary is ready (useful when a session involves multiple Virtual Users), and one that fires once the whole service session ends, with all summaries available together.
- Flow Actions: A action, "Get Virtual User Data" Ā to retrieve a summary by Service Session ID, optionally narrowed down to one specific Virtual User Session. This is useful when a session involved several Virtual Users and only one summary is needed.
š This new functionality needs to be certified and is not yet available in the official connector. If you want to test it early, install the Power Automate Connector as Custom Connector.
š”Privacy by design:Ā
- Summaries are only created for sessions with transcription consent. Without consent, no Virtual User transcription is stored and no summary is generated.
- Access follows the same permissions as the existing Companion Power Automate integration: Tenant Administrators and Service/Team Owners can execute both the trigger and the action.
Other Improvements
-
Personal Dashboards and Non-Personal Dashboards:Ā
-
Limits forĀ now scale to larger numbers of services and users. Maximum Dashboard limits are now shown in Extensions Tenant SettingsĀ settings, shown as read-only for transparency.Ā
š” This setting can only be changed by Luware System Administrators. -
Dashboard Widget Properties - Added āItems per Pageā setting to tabular widget properties. Allowed values are 1 to 100. The default is 10.Ā
ā® A pagination is shown in the widget footer with the currently displayed range and the total number of entries (for example 1ā100 of 320).Ā
š” This setting does not does not affect overall Dashboard query limits, just the page size.
-
Limits forĀ now scale to larger numbers of services and users. Maximum Dashboard limits are now shown in Extensions Tenant SettingsĀ settings, shown as read-only for transparency.Ā
- Extensions Tenant Settings > Nimbus Companion Interface - Removed dependency on Admin and Portal Companion Interface. Each Companion Interface can now be enabled individually.
- Nimbus Companion Ā - various smaller Companion-related icon changes in the Nimbus Portal UI (e.g. Attendant sidebar and Companion widgets).
-
Virtual Users - various quality of life improvements:
- āAdd Virtual Userā Workflow Activity: smaller cosmetic wording and layout changes, not affecting functionality.
- Virtual User config now has session/idle timeouts defaults defined, behaviors are explained in the KB.Ā
- Virtual User config > Outcomes are now protected against accidental deletion, show tooltip when outcomes are used in workflow activity exits.