Luware Knowledge

Nimbus Portal Nimbus Admin Nimbus Release Notes Luware Cloud Status
Home Luware Nimbus Release Notes

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

 
 
 

✅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:

  1. 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.
  2. 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.
  3. Once done and confirmed, get in touch with your Support representative, so we can switch your Tenant to the new presence service.

💡 Example of the consent link:

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.

02 September 2026 - 1.134 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 02/09/2026
Australia 01 03/09/2026
United Kingdom 01 08/09/2026
Switzerland 02 10/09/2026
Germany 02 10/09/2026
Switzerland 01 13/09/2026
Europe 01 16/09/2026
Germany 01 20/09/2026
Dates subject to change. Refer to https://status.luware.cloud/ > Scheduled Maintenance for the latest status.

Task Parallelization

Handling more than one task at a time no longer means manually parking what you're already doing first. With Task Parallelization, Nimbus users working on non-blocking tasks (such as Email or External Tasks) can now receive, switch to, and manage additional work while keeping their current task on hold in the background — keeping queues moving and giving users more flexibility in how they manage their workload.

New Task Assignment with Automatic Parking of Ongoing Non-Blocking Task

Nimbus users handling non-blocking tasks like Email or External Tasks can keep receiving new work exactly as if they were fully available — as long as they still have free capacity. This keeps queues moving and gets tasks to the right user faster, without waiting for someone to finish or manually park what they're already doing.

🔎 Added with this update:

  • Non-Audio/Video tasks can now be configured as Non-Blocking (or Blocking except Audio/Video). In case a user handles non-blocking tasks, they are still considered available for additional tasks. When handling a task which is Blocking except A/V, only Audio tasks will "break" through.
    The incoming task is shown above the connected one in My Sessions and Attendant Console, with an orange outline on the Active widget whenever a user has both a connected and an incoming task at once.
  • Accepting the incoming task automatically parks the connected task. Any unsaved changes on it (such as an email reply in progress) are saved automatically first.
  • User availability is now based on whether a user can still take on a task, not simply on whether they're already working on one: 
    • Available if they can still receive at least one more task.
    • Not Available once they've reached their task limit or their active task is a blocking one.

💡 Good to know

Existing user and service settings affect availability:

  • User Settings > Modalities: Per-user configured task limits (overall and per modality) still ensure that the user can't be overloaded by tasks and are always considered before assigning additional tasks.
  • Because availability is now capacity-based, a user already working on a non-blocking task can receive the next task before a fully idle colleague does, depending on the configured Distribution Policy (e.g. Longest-Idle).

RONA behavior remains:

  • 2 Declining or ignoring an incoming task doesn't change the state of an existing one. If Persistent RONA is configured for the service, the user is still flagged with RONA as usual.
  • If a user is flagged with RONA while still connected to another task, their user state shows RONA rather than Connected, so the need for attention stays visible. If a user receives a new invitation while already connected to a task, their state stays Connected rather than switching to Ringing, until they respond.

Allow to Enable Quick Switch Between Tasks

Switching between tasks so far was a conscious, manual decision to park your current task before you could pick up the next one. With the new Enable Quick Switch Between Tasks setting, Nimbus users can unpark a task directly: the currently active task is parked automatically, and the selected task is unparked in its place.

🔎 Added with this update:

  • A new user setting, "Enable Quick Switch Between Tasks" added to General User Settings > Task Parallelization. Allows users to opt-in to a one-step approach when switching between tasks. While enabled, unparking a task or starting a Call on Behalf automatically parks the currently active task, with no manual parking step required.
  • Changes to the setting are tracked in the Change History.
  • Note that this feature changes behavior in some existing Nimbus functionality:
Related Nimbus functionality Changed behavior
After-Call Work (ACW) 
  • Auto-unpark: The user continues directly with the task they unparked; there is no separate step needed to close out ACW first. If ACW cannot be ended – e.g. not extended, early end not allowed by service – it continues to run as configured, and the unpark proceeds once it's over.
  • Auto-end ACW (when allowed): Unparking a task while in ACW ends that ACW automatically, provided it's already been extended or the service allows ending it early.
  • Grace period for switching: Ending ACW this way does not trigger a new task to be distributed automatically, so the intended task switch isn't interrupted by an unrelated distribution.
Call On Behalf 
  • Auto-Park for Call on Behalf: With Task Parallelization enabled and remaining Audio/Video modality capacity users may start a Call on Behalf directly while another task is active — Nimbus parks the current task automatically. If the Audio/Video task limit has been reached in the meantime, the button is disabled with the tooltip: "You have currently reached the maximum AV task limit."
  • UI availability: The Call on Behalf button is enabled on all UIs — Assistant, My Overview, Services Overview, Attendant Console, and My Sessions — regardless of the type of task currently active.
Queue Distribution Type: Pickup
  • Pickup while non-blocked: Users working on a non-blocking task can deliberately pick up an additional task from the queue, when they have the capacity and skills for it. Task limits still apply — so Pickup isn't available once capacity is used up.
  • Pickup auto-park: Upon clicking “Pickup” on a new task, Nimbus parks the currently connected one.
  • Existing Pickup eligibility rules (skills, responsibility, etc.) remain unchanged.

☝️ Note the following limitations:

  • Quick Switching currently applies to Non-Audio/Video modality tasks. Support for Audio/Video modality tasks is planned as a follow-up update to Nimbus.
  • Parked Audio tasks still need to be accepted via the Teams toast notification. Failing to do so leaves both tasks parked — the previously active task stays parked, and the task that should have been unparked remains parked as well.
 

Virtual User Prompt Management via API

Managing Virtual User prompts and configuration no longer has to mean manual UI changes. With new Virtual User provisioning endpoints on the Nimbus API, customers can update Virtual User prompts and configuration programmatically — enabling versioning, releases, and rollbacks through their own CI/CD pipelines, in line with existing engineering workflows.

🔎 Added with this update:

  • New Virtual User provisioning endpoints on the Nimbus API:
    • GET Virtual Users — fetch a list of available Virtual Users.
    • GET Virtual User Details — fetch the full configuration of one Virtual User.
    • PUT Update Virtual User — update a Virtual User's configuration. Only the fields included in the request are changed; any field left out keeps its current value.
    • POST Copy Virtual User — duplicate an existing Virtual User, including its Tools and Outcomes, within the same Organization Unit, Bot, and Profile.
  • Fields that can be updated via PUT:
    • Text-based prompt fields: General Instructions, Outcomes & Tools Instructions, Initial/Final Message
    • Dropdown settings: Verbosity, Language, Virtual User Voice
    • Numeric fields: Max Session Duration, Inactivity Timeout
    • Modalities (currently Audio/Video only)
    • Virtual User License (true/false)

💡 Good to know:

✅ Precondition: To use this feature, the Provisioning Tenant Settings > “Enable Provisioning API” must be enabled.

  • The feature follows the same scoping (including Organization Unit) as the existing provisioning setting. Access is managed the same way as other Nimbus API provisioning capabilities: applications are configured in Azure AD by Tenant Administrators, who then grant the relevant permissions — Provisioning.VirtualUser.Read, Provisioning.VirtualUser.Update, and/or Provisioning.VirtualUser.Create.
  • A Virtual User must still be created in the UI first (or copied from an existing one with Tools and Intents) before its prompts and settings can be managed via API.
  • Updates made via the API don't affect sessions already in progress.
  • If someone is editing a Virtual User in the UI at the same time an API update runs, the last save wins.
  • After copying or updating a Virtual User via API, it still needs to be added to a workflow manually — unless the update is made directly to a Virtual User that's already part of one. A copy also has no license assigned until one is set in the UI.

Improved Data Privacy Tenant Settings behavior for Artificial Intelligence

Nimbus now warns Tenant Administrators before switching off an AI privacy setting, so a disable is never accidental. When Allow to use Companion or Allow to use Virtual User is turned off and saved, Nimbus shows a confirmation explaining that the change is irreversible and what will be reset as a result. Only after confirming does Nimbus apply the change — keeping consent and end-customer disclosure aligned with what's actually running on the tenant.

Previously, disabling either toggle in Data Privacy Tenant Settings and clicking Save applied the change immediately, with no confirmation step. Turning off Companion or Virtual User doesn't just disable the toggle, it also irreversibly resets the related AI Service Settings across every affected service — so this warning makes sure that's always a deliberate, informed decision.

Toggle Warning shown on disable + Save
Allow to use Companion "This action is irreversible. All Companion related AI Service Settings will be reset. Please confirm." — also removes the speech recognizer and the Transcription, Summarization, Codes, and Tags toggles across all services.
Allow to use Virtual User "This action is irreversible. All Virtual User licenses will be removed and Virtual User AI Service Settings will be reset. Please confirm."

🔎 Added with this update:

  • A confirmation warning when disabling either of these Data Privacy toggles and clicking Save, as detailed in the table above.
  • Confirming applies the reset across all affected services in a single action.
  • Cancelling leaves the toggle enabled and all AI Service Settings untouched — nothing is saved.

💡 Good to know:

  • The warning always appears when disabling and saving, even if the tenant has no existing Companion or Virtual User configuration — the confirmation isn't conditional on anything currently being "in use."
  • This mirrors the confirmation pattern already used when removing a Contact Center license from a user.

CRM Reference & User Lookup via Power Automate

Connecting Nimbus conversations to external CRM systems gets simpler. New Power Automate Connector actions let integrators reliably tie a session's transcript or summary back to the exact CRM record it belongs to, and identify the agent who handled it, without building extra lookup tables or requesting broad directory access.

A typical pattern could be: save the CRM reference when a call, email, chat, or WhatsApp task is first created, then retrieve it once the Companion or Virtual User transcript/summary is ready after the session ends — landing the transcript on the exact record created at the start, with no session-to-task mapping table to maintain.

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

Nimbus Power Automate connector - Release cycle and Update path
Customer Tenant Admin Procedures

Nimbus Customers can choose between following upgrade paths for the Power Automate connector: 

A: Update Path B: Migration Path
From the Custom Connector page, retrieve the V1 connector. Install it locally on your Tenant as a “custom connector”. When you are already using the custom connector, you need to migrate all your existing Flows to the certified connector from the Microsoft Power Automate store.
Benefits: Newest connector functionality is available as soon as the custom connector is installed. Benefits: Once migrated, future connector updates are rolled out automatically.
Drawbacks: Manual future Connector Migration effort. Drawbacks: Initial migration effort. Due to the Microsoft recertification process, the certified connector will get new features later.
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.

  • Once this approval is done, the submitted V1 connector becomes the new “certified connector" directly available in the Microsoft Store. Customers already using the certified connector get updates automatically. 
  • Flows may need minor adjustments (e.g. to make use of new Flow Actions / Trigger Events features).

💡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

Nimbus Power Automate connector - Release cycle and Update path
Customer Tenant Admin Procedures

Nimbus Customers can choose between following upgrade paths for the Power Automate connector: 

A: Update Path B: Migration Path
From the Custom Connector page, retrieve the V1 connector. Install it locally on your Tenant as a “custom connector”. When you are already using the custom connector, you need to migrate all your existing Flows to the certified connector from the Microsoft Power Automate store.
Benefits: Newest connector functionality is available as soon as the custom connector is installed. Benefits: Once migrated, future connector updates are rolled out automatically.
Drawbacks: Manual future Connector Migration effort. Drawbacks: Initial migration effort. Due to the Microsoft recertification process, the certified connector will get new features later.
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.

  • Once this approval is done, the submitted V1 connector becomes the new “certified connector" directly available in the Microsoft Store. Customers already using the certified connector get updates automatically. 
  • Flows may need minor adjustments (e.g. to make use of new Flow Actions / Trigger Events features).

💡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

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

Switzerland 01 https://portal.ch-01.luware.cloud/api/manifests/v1/PowerAutomateConnector.json
Switzerland 02 https://portal.ch-02.luware.cloud/api/manifests/v1/PowerAutomateConnector.json
Germany 01 https://portal.dewe-01.luware.cloud/api/manifests/v1/PowerAutomateConnector.json
Germany 02 https://portal.dewe-02.luware.cloud/api/manifests/v1/PowerAutomateConnector.json
United Kingdom 01 https://portal.ukso-01.luware.cloud/api/manifests/v1/PowerAutomateConnector.json
Australia 01 https://portal.aue-01.luware.cloud/api/manifests/v1/PowerAutomateConnector.json
West Europe 01 https://portal.euwe-01.luware.cloud/api/manifests/v1/PowerAutomateConnector.json
East United States 01 https://portal.use-01.luware.cloud/api/manifests/v1/PowerAutomateConnector.json
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.

  1. Go to https://make.powerautomate.com/ and expand Data > Custom Connectors.
  2. Select your Nimbus Custom Connector from the list.
  3. Click on the Context menu (three dots) at the end of the line. 
  4. Select “Update from OpenAPI file”.
  5. Click the "Import" button and select the new file.
  6. Finally click “Continue”.
    ⮑ The connector is now updated and should be visible on your Tenant.
 
 

🔎 Added with this update:

  • New CRM Reference & User Lookup Flow Actions for the (to be certified) Power Automate Connector:
    • Get details for a Nimbus User by Microsoft 365 object ID — given a Nimbus user ID, returns the Nimbus user's profile details (including UPN and first name), so a flow can identify the handling user without a separate Entra/Office 365 lookup.
    • Link an integration reference to a session Save Reference ID — Stores a third-party reference against a Nimbus session ID — for example a CRM unique ticket or case ID — so it can be retrieved later, once a session ends and its transcript needs to be written back to the correct CRM record.
    • Get an integration reference for a session Get Reference ID — Retrieves a previously stored third-party reference unique ID stored against an existing Nimbus session ID (either service, user, virtual user.

💡 Good to know:

  • Multiple references can be stored against the same session by using different Unique IDs — for example a CaseID, TicketID, and RequestID all tied to one session, each retrieved independently.
  • Stored references are retained for a maximum of 30 days, and aren't surfaced anywhere else in Nimbus (e.g. not shown in My Sessions, Attendant Console, or Reporting) — they exist solely for retrieval via these two actions.
  • Nimbus doesn't automatically sync these references with your external system; keeping them updated in the third-party system remains the responsibility of your flow.

Emergency Manual Presence Mode

With the new Emergency Manual Presence Mode, Nimbus Admins can switch routing to a system-controlled presence state that users set directly in Nimbus — keeping task distribution reliable when Microsoft Teams presence data is delayed, missing, or otherwise unreliable.

Area Previously With Emergency Manual Presence Mode
Presence source Routing always depends on Microsoft Teams presence. Admins can switch routing to a manually controlled presence state in Nimbus.
Agent availability Agents have no way to signal availability if Teams presence isn't syncing. Agents set themselves to Available or Appear Offline directly in Nimbus.
Unset agents N/A Agents who don't set a state are treated as Offline, avoiding accidental task assignment.
Duty profiles / team settings Applied on top of Teams presence. Continue to apply unchanged, now on top of the manual state.
With Emergency Manual Presence Mode enabled, a simplified presence can be set via the User Avatar

🔎 Added with this update:

  • Extensions Tenant Settings: Added new Emergency Manual Presence Mode setting under Admin > Tenant > Extensions > Presence Tracking.
  • While enabled:
    • Nimbus stops syncing presence from Microsoft Teams for that tenant, and users instead set their own state from a new dropdown on the avatar icon, available on My Overview, My Sessions and Attendant Console.
    • The manually set presence state is reflected across Dashboards, Live View, Overviews, and Nimbus Assistant.
    • Users can choose their presence by clicking their avatar in the Nimbus header. 
    • Two presence states can be selected : Available and Appear Offline.
    • Two responsibility profile selections: On Duty and Off Duty. 

💡 Good to know:

  • Task routing continues to respect existing Responsibility Profiles (OnDuty/OffDuty) and MS Teams-based Active/Inactive settings; only the underlying presence source changes.
  • Users that don't actively set a state are automatically treated as Offline, so no one is unintentionally included in routing.
  • Enabling or disabling the setting, or changing a manual state, doesn't affect active sessions already in progress.
  • After disabling the mode, delays in the automatic presence synchronization with Microsoft may occur. If your presence doesn't reflect your actual Teams status shortly after disabling, use Reset status from your Teams presence dropdown to resolve it.
  • Disabling the mode automatically removes the states dropdown from the UI and resumes normal Microsoft Teams presence syncing.

Attendant Console: Full PSTN Number Support for Nimbus Services

With this feature, the Attendant Console fully supports PSTN numbers of Nimbus services across contact cards, detail panels, transfers, and consultation calls.

🔎 Added with this update:

  • The PSTN number of a Nimbus service is now shown wherever that service's contact information is displayed — including contact cards and the detail panel — with a Call To button available directly there.
  • PSTN numbers of Nimbus services are no longer excluded from transfer and consultation call targets in the Attendant Console.
  • When an agent selects a service's PSTN number as a transfer or consultation target, Nimbus automatically routes it as a native service transfer or consultation — preserving full queue management, call handling, and reporting.

💡 Good to know:

  • Targeting a Nimbus service by its PSTN number now behaves identically to targeting it by name — no extra steps or confirmation needed from the agent.

Terminology Changes

💡 In order to keep up with the ongoing changes and new concepts in Nimbus, terminology was streamlined and consolidated. The goal was to rename existing concepts across all Nimbus surfaces without changing any underlying calculation logic. This decouples "cleanup" from “new behavior”. Changes therefore primarily focus on Nimbus concept pages and the UI, not the Nimbus Reporting Model or any functional behaviors.

To make this change easier to follow, we marked the most prominent Affected Nimbus UI areas as follows:

Old term New term Affected UI Areas

“Available”

(in Reporting: Selectable)

“Ready”

Renamed to avoid mix-up with Microsoft Teams status.

(Reporting remains unchanged “Selectable”)
  • Contact Center Assistant 
  • Nimbus Assistant
  • Services Overview
  • Live View
  • Distribution Policies

“Not Available”

(in Reporting: Not Selectable)

“Not Ready”

Renamed to avoid mix-up with Microsoft Teams status.

(Reporting remains unchanged “Not Selectable”)
“Not Available Reasons” “NAR” (still used synonymously with “Not Available Reasons”). NAR may be appearing as abbreviated alternative, synonymous with NRR (Not Ready Reasons).
“Active/Inactive”

“Ready / Not Ready”

Standardized to avoid ambiguity and reduce terms:

  • A combination of MS Teams Presence1 AND either Nimbus User States fulfilled:
    • "Active" toggled for MS Teams Based services.
    • An “On Duty” type Responsibility Profile selected.

1💡 Service Distribution Service Settings may still allow “Busy” or “Away” users to be appear "Ready" for new Nimbus tasks. The wording change is only cosmetic.
  • User Status Headers 
“Duty”

Now distinguished by Responsibility Profile Type:

“On Duty / Off Duty”
  • Nimbus Configuration
  • User Responsibility Profiles
  • Filters in Flexible Dashboards
  • Status Tooltips
“Duty Profile”

“Responsibility Profile” 

Renamed to avoid mix-ups with profile type “On / Off Duty” Duty States. Clarify that “Off Duty” is actually a part of Responsibility Profiles configuration.

“Duty Profile Type”

 

“Responsibility Profile Type”, either: 

  • On Duty
  • Off Duty
  • Flexible Dashboards
  • Configuration (Responsibility Profiles)
“Time in Duty Profile”

“Time in Responsibility Profile”

Standardized 
  • Flexible Dashboards

🔎 Notable KB page changes for terminology changes were as follows: 

Other Improvements

  • Virtual Users: quality of life improvements:
    • Improved the Virtual User capabilities to allow callers to barge-in (interrupt existing sentences) if needed.
    • Newly created Virtual Users no longer need to be saved first before the license can be applied.
  • UI change: User Administration > Not Available Reasons > “NAR”: 
    • Tab renamed from “N/A Reasons” to NAR to avoid confusion with “N/A Not Available” terminology.
    • 💡No functionality changes on the tab itself.
  • Licensing Icons change - “light” style icons for Nimbus are now used in the UI, same as already shown on Nimbus Features.
  • Distribution Service Settings restructured slightly for “Busy” status:
  • Flow Actions - “Download Recording” added for Power Automate Connector certification. 
    • Downloads the audio of a call or Voicemails recording, given its Call ID and Recording ID. 
    • The “When a voicemail is ready” Trigger Events related to this action remains unchanged, documentation was updated.
Nimbus Features

Focus Features Discover how Luware Nimbus features can help you transform your cu...

Release Note History (2026)

History Overview This page will be updated with releases from 2026 onwards. For p...

Table of Contents