Latest Release Notes

Stay informed about the latest updates on Nimbus

This page will always reflect the latest Release Notes, recent improvements and changes made to Nimbus.

Other Information 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 10'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.nextLink out 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 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.

🔎@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:

  1. The data client generates a request to the OData service.
  2. The OData service responds.
  3. The presence of @odata.nextLink in the response indicates that the server has more data available.
  4. Clients must continue issuing requests using the provided URL until no @odata.nextLink is 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
  • Reads the page
  • Follows @odata.nextLink
  • Repeats until no link exists
  • Avoids performance-related timeouts from large datasets and “race conditions”
  • Would request huge result sets
  • Assumes pagination is the server’s responsibility
  • APIs run out of memory
  • SQL queries lock tables
  • Refreshes may fail or timeout
 
 

🤔Which Nimbus data is affected?

Impacted OData entities from the Nimbus Reporting Model and Data Aggregation are as follows: 

  • ServiceSessionsAggregates
  • UserSessionsAggregates
  • UserStatesAggregates
  • ServiceSessions
  • UserSessions
  • UnifiedSessions
  • TransferSessions
  • Callers
 
 

🤔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.

 
 
 

End of announcements. Regular release notes continue below.


06 May 2026 - 1.128 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 06/05/2026
Australia 01 07/05/2026
United Kingdom 01 12/05/2026
Switzerland 02 / Germany 02 14/05/2026
Switzerland 01 17/05/2026
Europe 01 20/04/2026
Germany 01 24/05/2026
Dates subject to change. Refer to https://status.luware.cloud/ > Scheduled Maintenance for the latest status.

Virtual User Extended with Web Requests

INC Preview Feature

This feature is in PREVIEW and may not yet be available to all customers. Functionality, scope and design may change considerably.

Web Requests extend the capabilities of Virtual Users by enabling direct integration with external systems through configurable API calls. This allows organizations to go beyond intent detection and implement advanced automation scenarios, such as CRM lookups, customer verification, and self-service workflows. As a result, more interactions can be handled automatically, reducing agent workload and improving response times. With built-in testing, error handling, and tenant-level controls, integrations remain secure, reliable, and easy to operate.

🔎Added with this update:

  • A new Bot Type Nimbus AI Service - AI Workflow to be used as a Virtual User.
  • Configurable Web Requests as part of the Virtual User instruction set.
  • Web Request responses can be stored as Parameters and used throughout the session.
  • Using the Virtual Users in Audio/Video Workflows -  The virtual user dynamically handles the customer interaction with Web Requests in the background and provides exits for Fallback, Success, Failure and Idle Timeout scenarios.

Model Context Protocol (MCP) Server Extension for Virtual User

INC Preview Feature

This feature is in PREVIEW and may not yet be available to all customers. Functionality, scope and design may change considerably.

With MCP Server support, Virtual Users can be extended with ready-to-use integrations to handle a wider range of scenarios. The MCP server integration connects your Virtual User to external tools or services through an MCP (Model Context Protocol) server, which acts as a bridge between the AI and those systems. Instead of configuring API requests, you can use plug-and-play capabilities provided by third-party platforms, reducing setup complexity and implementation time. MCP Servers also enable low-latency voice interactions, supporting more natural and responsive conversations. By connecting multiple MCP Servers, organizations can further expand their automation use cases and increase the overall value of their Virtual User.

🔎Added with this update:

  • Virtual User: MCP Server configuration options as part of the new Bot type “Nimbus AI Service - AI Workflow”. If a Virtual User is using this bot type, the Extension Tools section on the Virtual User's configuration page allow settings for Web Requests and MCP.
  • The option to enable multiple MCP Servers per Virtual User.

Task Parallelization: Increased to 4 parallel tasks in any modality

With this feature, Luware Nimbus gives administrators granular control over how many tasks a user can handle simultaneously. A new Total Task Limit (up to 4* Tasks) sets the overall maximum across all channels, while individual Task Limits per  user — for Audio/Video, IM, Email, and External Task — allow fine-tuned configuration per role or team. This replaces the previous fixed limit of two parallel tasks. As a result, organizations can better balance agent efficiency and workload, ensuring users are neither underutilized nor overwhelmed — without the need for manual workarounds or custom routing logic.

*The maximum limit will be gradually increased in future releases.

🔎Added with this update:

  • General User Settings: Added four new fields Task Limit per modality for Audio/Video, IM, Email, and External Task. 
  • Added a new field Total Task Limit controlling the overall maximum number of parallel tasks per user. Current limit: 4.
    💡If combined Task Limits across modalities exceed the Total Task Limit, the Total Task Limit still applies.
  • Modality restrictions for parallel tasks have been lifted. As Parking remains the prerequisite, according KB pages and comparisons with “On Hold” tasks have been updated.
New configurable task limit in the General User Settings

ACW now configurable for unsuccessful Outbound calls

Administrators are now able to grant ACW in cases where the destination is not picking up so that the users (agents) can fulfill their obligations, like documenting the attempt or scheduling another call to the destination. This feature applies for Nimbus users which are already "connected" (call on behalf task accepted, or scheduled outbound call accepted) but cannot successfully reach out to the customer. It will not apply for Outbound call with workflow, as the destination is first pre-dialed out to, then the user needs to accept the task.

New ACW option for Unsuccessful Outbound calls

🔎Added with this update:

  • Distribution Service Settings > After-Call Work (ACW): Added new toggle “ACW for Unsuccessful Outbound” (default disabled). Starts ACW in case outbound call ends with destination not reached, destination declined or user aborted.
  • Outbound Call - updated chapters in the KB to clarify the relation ACW and under which scenarios this toggle applies.

Other Changes and Improvements

  • Provider Connector - Administrators can now validate the configuration of a Twilio Provider Connector and its associated Messaging Entries directly from the UI, confirming API connectivity and verifying available messaging capabilities (SMS, WhatsApp) without requiring a full save of the configuration.
  • Personal Dashboards  - Dashboard Widget Properties - Columns, Filters and Thresholds for “User State Tabular” and “User Supervision” widgets have been updated. Tabular widget table headers: Renamed instances of “Time in state” to "Time in Presence State" to make the distinction clear. 
  • User Preferences (Admin): Now offering download links for Power BI Template and Nimbus Assistant

Table of Contents