General Service Settings

Contains general service settings such as the Service name, PSTN number, Opening Hours and Reporting settings.

The "General" tab provides options that relate to Nimbus provisioning. Here you can also initiate "Test Calls" via MS Teams, which is particularly useful when you want to test changes to your Workflows. As a Service / Team Owner you can see the following details.

🔍Note: Entries marked with ☝ require a (re)execution of a Provisioning Script. → See Note below on "Triggering Changes / Admin Consent"

Name  - Name of the Team as it is defined in Microsoft Teams client. Nimbus 
Service Display Name

Outwards facing Clear Name of the Service as Callers / Customers will see it in their Client.

💡 By default equal to the "Team" Name as it is shown in Microsoft Teams. Can be overridden if needed.

Service UPN The UPN (User Principal Name) under which the Service can be reached via user directory.
Application ID - The Application ID is provided during initial setup and cannot be changed. Used only for reference, e.g. during support cases or when adjusting Required App Permissions
Test Calls -

A test call will directly call the Nimbus call-bot and establish a connection to your service. You can use this feature to test your workflows and/or distribution settings.

💡 Please note that this feature will not test any PSTN numbers assigned to your service. To test a PSTN you need to call via cell phone or landline.


  • Nimbus bot operation is not affected by service name changes. Calls will continue to be distributed.
  • A service name change will also not impact the (search-discoverable) service UPN name specified.
  • Nimbus users will see team name changes reflected in their "My Teams" listing immediately.

💡 As team owner you can change your team name directly within Microsoft Teams (native, non-Nimbus functionality):

  1. Within MS Teams, locate your team 
  2. Click on the "..." icon or right click the team name
  3. Select "Edit Team" → A dialog will open
  4. Change the team name (and optionally the description) to any desired content. → The Nimbus "settings" tab will reflect the new team name upon next load. 

UPN and Service Display name changes are tied to Tenant Admin Consent and provisioning script rerun which can take several minutes to take effect. Any change is therefore marked with a ☝ Warning in the UI.

🔍 I'm a Service Owner - why are certain Service settings still locked against change? 

  • The full amount of settings is accessible only to Tenant / Partner administrators. Certain features are part of the Nimbus installation procedure and cannot be changed past deployment without provisioning a new service again.
  • Certain changes are bound to the Service type or License applied. A downgrade may be prevented until you disable certain Nimbus Features or delete involved data entities.

🤔 I'm having technical questions before changing my service settings. Where can I find help?



Allows to assign a public telephone number (Public Switched Telephone Network) to your service. 

☝ This setting should not be enabled without subject-matter knowledge or prior Tenant Admin / Nimbus support contact consultation.

🤔 Refer to the Installation Prerequisites for further info on PSTN / Number requirements.

🤔 Why is this necessary? Administration and licensing of PSTN numbers is outside of Luware control. Erroneous Number and License assignment may result in additional set-up efforts and running costs. Get in touch with your Nimbus support representative if you need help with this setting anytime after your initial Nimbus deployment. Our FAQ and Troubleshooting section is also updated frequently.


Opening Hours

Allows you to apply Opening Hours for your service team. Handling and routing based on opening hours is part of your Workflows e.g. by routing the call according to the "Check Opening Hours" Workflow Activity.

✅To be selectable in this Opening Hours entry (data entity) must be created first - and made available within the same Organization Units of the service or Tenant-wide.

Define primary and secondary opening hours

Each team may decide if the opening hours are defined as primary or secondary. This is determined via service-individual Service Settings > "General" Tab.


Opening Hours Period Ruleset:

  1. If at least one defined period is found in the primary opening hours calendar, this period is prioritized.
  2. If there is no period in defined primary calendar, the secondary calendar period is applied.
  3. If no appointment is found in either calendar (with a secondary configured), the "Default" state of the first calendar is used.
  4. The default of the secondary calendar never applies in a two-calendar scenario. If the secondary calendar has no periods defined it is effectively ignored.

🔍 Rule of thumb: Primary Defined? > Secondary Defined? > Both no? > Use Primary Default!

💡 An example of how this rule is applied can be found below.

Service Settings with applied opening hours. The current applicable status is shown under "Active Opening Hours".


Show me an example

In this example there are two calendars defined: one provided the Admin (e.g. Company-Wide special holidays) and one "Service Specific" calendar created by a Team Owner.  

💡 For simplicity we're assuming these calendars operate on a "whole day" basis for one week.

💡 Each day will be handled differently to illustrate a case from the rules above.

The calling customer will experience the service status as follows:

  • On Monday the primary calendar has a "holiday" defined. → The service workflow will react according to the path defined for holidays (usually a closed-announcement), otherwise the default applies (also closed).
  • On Tuesday the primary calendar is default "closed", however the secondary has a special period defined. → In this case the the secondary calendar takes precedence.
  • On Wednesday the primary calendar is default "closed", however the secondary has an "open" period defined. → In this case the secondary calendar "open" period takes precedence.
  • On Thursday the primary calendar and secondary calendar have a default status, but no specific periods defined. → The primary default "closed is used, secondary default gets always ignored.
  • On Friday the primary calendar has a special event type defined. → Depending on how the service workflow is configured, it will react to the "special" primary calendar period (e.g. same as Tuesday).


🔍These values are mandatory Service Level Agreements (SLA) to specify as they are integral part of your team's Reporting and the Nimbus Reporting Model KPI calculation.

SLA Acceptance Time in Seconds

Maximum allowed time in queue before a task (read: incoming call) in the Dashboard is flagged as outside of SLA. 

🔍 Shows as "Acceptance SLA" in both Reporting and historic Power BI reporting. Directly relates to Nimbus KPI Calculations.

SLA Hangup Time in Seconds

Maximum allowed time in which the caller can hang up on a call without it being flagged as outside of SLA.

🔍 Shows as " Hangup SLA " in both Reporting and historic Power BI reporting. Directly relates to Nimbus KPI Calculations.

💡 Hung-up calls will still be considered as failed and thus show up as "Hangup in Queue" (red) in Reporting.

Short Abandons Threshold in Seconds

Maximum allowed time until the call is marked as “Abandoned” in the Nimbus Reporting Model.

💡 Default: 5s, min 1s, max 30s

Show on Historical Sessions Page

Default: enabled. 

GRPR - When disabled, the service and its related task results will not appear in the Historical Sessions view.


TENANT ADMIN Privacy setting - To be compliant with GDPR regulations and respect Nimbus user privacy you can hide the "User Statistics" widget from the Service's respective Reporting view.

TEAM OWNER As service / team owner you may check on this setting, but not change it.

 When enabled:

→ All Nimbus users of this service will not be able to inspect the "User Statistics " > (not) accepted tasks" anymore. This also includes team owners / service administrators.
→ The "Task Heatmap" widget will utilize the remaining space within the Reporting view.

💡 Note that this setting is only affecting the Frontend reporting and not the actual Nimbus Reporting Model backend data. You can still evaluate / anonymize call data within Power BI Paginated Reports.


Table of Contents