Luware Knowledge

Nimbus Portal Nimbus Admin Release Notes Service Status
Home Nimbus Usage of Nimbus Service Settings

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

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.

CHANGING A SERVICE DISPLAY NAME

  • 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?

  • Check theĀ FAQ and TroubleshootingĀ section for our most common questions, technical use cases and support details.
  • Many technical configuration details are explained on ourĀ Nimbus InstallationĀ andĀ Service ProvisioningĀ pages. If you have further questions, our success team will gladly support you.
Ā 

PSTN

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.

RULESET: PRIMARY AND SECONDARY OPENING HOURS

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

Reporting

šŸ”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 in a queue without the call 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.

GDPR - HIDE USER STATISTICS FROM REPORTING

Tenant Administrator 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 a 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 and service administrators.
ā†’ The "Task Heatmap" widget will utilize the remaining space within theĀ ReportingĀ view.

šŸ’” Note that this setting is only affecting frontend reporting and not the actualĀ Nimbus Reporting ModelĀ backend data. You can still evaluate/anonymize call data withinĀ Power BI Paginated Reports.

Ā 

Licenses & Addons

In these sections, you can assign licenses and addons to the service. Available tabs and settings depend on the assigned licenses/addons.

Service Settings

Good to know Service settings are available Nimbus service / team owners. You can...

Service Provisioning

Before you start The Nimbus Installation must be completed before you can start w...

Provisioning via Microsoft PowerShell

šŸ’”We automated the provisioning steps in a PowerShell script for you. It will conn...

Table of Contents