Latest Release Notes

Stay informed about the latest updates on Nimbus

📣Important Announcements

Please take note of the following long-term and ongoing announcements below:

INC .NET Phase Out Notice

Microsoft .NET 8 Phase Out - Administrative action required

☝️ Microsoft is ending .NET 8 Support on Nov 10, 2026. Existing Assistant installations will continue to operate, however without future Microsoft support and security updates, which poses a potential security risk.

✅ What Tenant Administrators need to do:
  • Nimbus User / Agent PCs which have Nimbus Assistant installed will need the latest update installed. The latest Nimbus Assistant Setups can be retrieved from the User Preferences (Admin Portal).
  • The new and all future Nimbus Assistant Installers will now require .NET10 dependencies to be installed, as described on the Nimbus Assistant Installation > Preconditions. 
    💡You can leave .NET 8 installed on client machines, should you require it for a transitionary period or for other installed apps.
 

✅Admin Action Required: Migration to new Presence Service

🔎 What it is about: The Nimbus presence service tracks each agent's real-time MS Teams status (available, busy, in a call, away), so Nimbus only routes customer calls to agents who can take them. Presence is currently polled from Microsoft Graph in three ways:

  • Application permissions (current standard)
  • Federation (deprecated)
  • Guest accounts (deprecated)

☝️ Why migration is needed: Microsoft has deprecated federation and guest-account polling. The new presence service is built on application permissions only.

⚠️ Deadline: Please complete this by end of February 2027. From March 2027 the older methods are switched off, and presence updates will then stop if the application permissions have not been granted.


✅ What Tenant Administrators need to do:

Tenants already using application permissions: no action required.

Tenants still using federation or guest accounts: complete this one-time step before the legacy service is switched off.

  1. Ask a Global Administrator of your Microsoft tenant to open the link below and grant admin consent to the Nimbus application. Replace <tenantId>
https://login.microsoftonline.com/<tenantId>/adminconsent?client_id=af85ba37-5817-43d6-82e7-09004f08664e
  1. Alternatively, re-run the Provisioning PowerShell script.

If you run into issues or have questions, contact support via our Helpdesk.

 

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

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


4 November 2026 - 1.137 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 04/11/2026
Australia 01 05/11/2026
United Kingdom 01 10/11/2026
Switzerland 02 12/11/2026
Germany 02 12/11/2026
Switzerland 01 15/11/2026
Europe 01 18/11/2026
Germany 01 22/11/2026
Dates subject to change. Refer to https://status.luware.cloud/ > Scheduled Maintenance for the latest status.

Virtual User Session Reporting in OData

Virtual User Sessions are now part of Nimbus historical reporting in OData, using the same session structure as User Sessions. Supervisors and report builders can compare how many conversations are handled by Virtual Users and by human agents, see how these conversations end, and identify where a Virtual User needs fine-tuning. Virtual User data is kept separate from human user data, so existing reports and dashboards stay unchanged.

🔎 Added with this update:

  • Facts - Columns and Data Types -Three new Reporting Tables: Virtual Users (who the Virtual User is, for example its name, Organization Unit, Bot and Virtual User Profile), Virtual User Sessions (for example the modality, start and end time, connected time and outcome of each conversation), and Virtual User Session Outcomes.
  • Slowly Changing Dimensions - Dedicated Session Outcomes: Successful, Failed, Timeout, Fallback and Customer Hangup – so you can see at a glance which conversations the Virtual User resolved on its own and which ones needed a human agent.
  • Nimbus Reporting - Virtual Users in Service Sessions: Service Session reporting also shows when a call ended during or right after a Virtual User conversation.
  • Reporting Roles - New Virtual User Supervisor Role Permission: Tenant Administrators can give users the new Virtual User Supervisor permission on the Users page of the Admin Portal. This way, you decide on purpose who gets to see Virtual User reporting.

💡 Good to know:

  • OData only: This first step adds Virtual User reporting to OData. Power BI template updates and reporting views in the Nimbus Portal or Admin Portal will follow in later updates.
  • Existing User Supervisors don't see Virtual User data unless they are also given the Virtual User Supervisor permission. Virtual User Sessions are visible to Tenant Administrators, Service and Team Owners, Team Owners (Limited), Service Supervisors and Virtual User Supervisors.
  • Only Virtual User sessions that take place after the release are reported. Past sessions are not edited in post to not impact existing reports.
  • Virtual User session data follows the same data retention policy of a maximum of two years.

Virtual Users: Automatic Re-Engagement on Caller Inactivity

When a caller stops responding during a conversation with a Virtual User, the Virtual User now re-engages them automatically. If the caller still doesn't respond, the call follows the Idle Timeout path configured for the Virtual User, so every call ends in a defined way.

🔎 Added with this update:

  • Virtual Users “Inactivity Timeout” - Automatic re-engagement on caller inactivity: After 10 seconds of inactivity, the Virtual User re-engages the caller, for example by asking whether they are still there, and tries once more after another 10 seconds.
  • Defined ending: If the caller still doesn't answer, the call follows the Idle Timeout path you have already set up for your Virtual User.

💡 Good to know: While the Virtual User is still waiting for an answer from one of its tools, it doesn't interrupt. Longer lookups should still be announced to the caller beforehand.


Scheduled Outbound Calls for Direct Call Handling Services

Scheduled outbound calls now also work with Direct Call Handling. Your CRM, booking tool or customer portal can schedule a call for a user's Direct Call Service through the Nimbus API or the Nimbus Power Automate connector. When the call is due, Nimbus offers it to the user who owns the Service. Once they accept, the customer is called from the user's own direct line. This removes the need for manual callback lists or reminders, and customers see a number they already know.

➕ Builds on existing features: This extends Direct Call Handling and the Scheduling of Outbound Calls (Callback) in the Nimbus API, which were introduced with the previous release.

💡Please note that Power Automate changes listed below need to undergo MSFT certification and will become available once passed.

 

🔎 Added with this update:

💡 Good to know:

  • The Direct Call Handling service needs a resource account, which provides the user's direct line. Without one, the call can't be scheduled.
  • Services based on Nimbus Unify are not supported yet. To change the time of a scheduled call, cancel it and schedule a new one.
  • For calls scheduled through the Nimbus API, Nimbus checks the Service's opening hours again when the call becomes due. Calls scheduled through Power Automate are not checked again.
  • Offered to the owner, called from the direct line: At the scheduled time, Nimbus first offers the call to the owner of the Direct Call Service and then dials the customer. The customer sees the owner's direct line.
  • Same settings as other scheduled calls: Number of attempts, retry interval, ringing time and priority work the same way as for all other scheduled calls.
  • Included in reporting: Scheduled calls on a Direct Call Service count towards the owner's user statistics. An offer that isn't answered counts as RONA.

Nimbus Call on Behalf from a CRM

Integrations such as a CRM can now start a Call on Behalf for a user through the Nimbus API or the Nimbus Power Automate connector. Nimbus rings the user first. As soon as they accept, Nimbus dials the customer from the Service's number; on a Direct Call Service, this is the user's own direct line. Users no longer need to type numbers or switch between the CRM and Nimbus, and the call can be matched back to the right CRM record afterwards.

🔎 Same call, new starting point: This works like a Call on Behalf that a user starts in a Nimbus client. The difference is that your own system starts it.

 

🔎 Added with this update:

  • Start a call from the Nimbus API > Outbound Calls with the new method POST Start a Call on Behalf (Click-to-Call)
  • Start a call from Power Automate: New Flow Action > Outbound Calls: “Start a call on behalf”.

💡 Good to know:

  • The user must be a member of the Service. On a Direct Call Service, this is its owner.
  • The user must be available for an outbound call. Otherwise, the call isn't started.
  • Straight to the user: The call doesn't wait in a queue. It goes directly to the user who should make it.
  • Context travels with the call: Information from the CRM record, such as a customer or case number, can be passed along with the call. The user sees it during the call, and your workflows and flows can use it.
  • Match the call to your CRM record: Each call carries a reference that your Power Automate flows receive with the call events, so the call can be linked back to the right record.
  • Included in reporting: The call is reported just like a Call on Behalf started in a Nimbus client. On a Direct Call Service, it counts as an outbound direct call of the user.

Click to Call in Nimbus Assistant now supports links using the consultation protocol, for example shown as part of your current context. If you're in a call, clicking such a link starts a consultation with the colleague or Service. If you're not in a call, or handle a task of a different modality, Nimbus Assistant opens a dialer with the number already filled in, so nothing is dialed by accident.

🔎 Added with this update:

✅ Administrator action required: A new Assistant App Update is needed to support the new consultation protocol. Consultation – like any other call links – must be registered on the user's computer. This is done by your IT team. The Nimbus Assistant installer doesn't do this automatically.

☝️ Related Important Update Note: The Nimbus Assistant Installation now requires .NET 10, due to the planned .NET 8 support phase-out by Microsoft. A timely update of Assistant is highly recommended, regardless of the new feature described above. More information can be found on the Assistant Installation Page > Preconditions.

 

Consumption-Based Licensing: See Your Usage

Nimbus now measures how many minutes your organization uses for Companion transcription and for Nimbus Unify calls. Administrators can see in the Admin Portal how many minutes have been used in the current period, how this compares to the allowance agreed for the tenant, and how it compares to the previous period. This makes usage transparent and easier to plan for.

💡 Note: In this first step, usage is only measured and shown. Nothing is blocked, limited or charged when you reach or exceed your allowance. All features keep working as before.

 

🔎 Added with this update:

  • License Management - Consumption Licenses overview: A new overview on the Licensing page of the Admin Portal shows the minutes used per month for Companion transcription and Nimbus Unify.
  • Consumption Tenant Settings - New Tenant Administration tab: Shows the allowance and the usage of the current period at a glance, together with the previous period.

💡 Good to know:

  • Allowances are set by Luware. Tenant Administrators can view them once an allowance has been applied to their tenant.
  • Usage is recorded tenant-wide, not per service or user. The overview is part of the Admin Portal Licensing page and is visible to all Admins.
  • Measured separately: Call time counts towards Nimbus Unify, transcribed time counts towards Companion transcription. Nothing is counted twice.

Other Changes and Improvements

  • Nimbus Assistant Installation / Nimbus Assistant: Added .NET8 deprecation and migration notice to the KB.
  • Nimbus Companion Interface: Various UX improvements to split-screen mode, collapse/expand alignment, and chat search.
  • Virtual Users: Initial message is spoken exactly as configured - The Virtual User now speaks the configured initial message exactly as written, without translating it. If the initial message is written in several languages, for example English and German, callers hear every language just as it was entered, so they can pick the language they want to continue in.
  • KPI Calculations “Destination Accepted”: The Destination Accepted KPI now reflects the external party answering the call. Previously, it reflected the Nimbus user accepting the outbound task. 
  • Dashboard Widgets in Personal Dashboards - Improved percentage-based KPIs display when no data available: The percentage KPIs Acceptance SLA, Hangup SLA, Reachability, Outbound Reachability and Handled Rate no longer show 0% when there is nothing to measure in a period (e.g. no queued outbound tasks). KPI tiles and tables now show “-”, and graphs, look-back charts and comparison charts leave a gap for that period instead of a 0% data point.
  • Provisioning via Microsoft PowerShell - Slight KB page restructure. Clarified requirements for using a Regular PowerShell window, the script won't work within PowerShell ISE.
  • Task Flow Visualizer - “Now” lane: In Live Mode, the Drop-off flow shows a “Now” lane in front of the finished-task lanes. It shows what is happening in the selected Service right now, so you can act while traffic is live instead of only seeing afterwards where tasks were lost. The “Now” lane is not shown in Replay Mode.
  • Opening Hours Updated time-zone dependencies to reflect Alberta and British Columbia permanently ending seasonal clock changes and staying on year-round daylight saving time, starting November 1, 2026.

Table of Contents