Service Settings

Before you access Settings

Service settings are available to service (team) owners TEAM OWNER. You can access them via Nimbus's Frontend menu or in the team headers.
Tenant administrators TENANT ADMIN have extended access to service settings via the Administration backend.
Regular users TEAM MEMBERS (Agents) will not see the settings option at all.

Notes:

Settings rely on shared data entities managed via the central Nimbus Configuration. We highly recommend to check there first before adjusting your settings to avoid having go back-and-forth.
Settings- and options visibility is determined by Organization Units (OU) and Role Access Concept. Access to certain features may be hidden from view or locked, despite having an admin role.
To reduce complexity, settings may be hidden as licensing or Nimbus Features must be enabled first.

Settings Tabs

The tabs contents below reflect the service settings available in the Nimbus UI. Please note that some tabs are restricted to certain Service types and show when related Nimbus Features are enabled.

General

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.

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

Within MS Teams, locate your team
Click on the "..." icon or right click the team name
Select "Edit Team" → A dialog will open
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.

Triggering Changes / Admin Consent

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:

If at least one defined period is found in the primary opening hours calendar, this period is prioritized.
If there is no period in defined primary calendar, the secondary calendar period is applied.
If no appointment is found in either calendar (with a secondary configured), the "Default" state of the first calendar is used.
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 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.

Hide User Statistics from Reporting

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.

Workflow

Shows workflow related settings. Use the pull-down to choose any of the Workflows of your team.

Note that you can switch between workflows available within your Organization Units but not edit their structure from within this tab. Defining workflows is part of Nimbus Configuration.

Potential live business impacts!

Note that changing or editing any productive Workflow will immediately apply to your current service once you press "Save and Apply". In case of an incomplete or erroneous workflow this may cause interruptions to your daily service, including lost calls.

If you want to make changes without impacting current productive work, make changes in the workflow tab instead, e.g. by working on a separate workflow that you can test on a separate service team first. When finished editing you have the possibility review changes first before setting the new workflow as your productive one.
Experimental or "in progress" workflows should be moved to Organization Units where productive services cannot see and select them.
We recommend to perform workflow switches at certain defined points in a day (e.g. breaks) or outside productive business hours.

All existing call sessions will be handled with the workflow settings they were originally created with. Already queued tasks will not be directed to another workflow.

Voice Message Channel

Some workflows can contain steps that create voice messages, e.g. shown within Adaptive Cards. Any Microsoft Teams channel within your team can be used, "General" being the default.

Nimbus chat bot will automatically post voice messages to the new channel, however existing messages are not transferred.

Distribution

Contains settings related to call distribution.

Note that - once applied - these settings affect all current or future users in this service.

Users

Allows to configure settings that affect Nimbus user status handling and call distribution.

User Assignment Type

Shows how (new) users are assigned to this service. → See User assignment types.

The default for Nimbus is "Microsoft Teams Based". Users are directly synched to the Teams channel related to the current service.

Why is this setting locked? The assignment type is determined during Service Provisioning.

Distribution Policy

Contact Center Service Type feature.

Why is this setting locked? Distribution Policies are managed and changed via the Service Administration, depending on your service type and licsense.

New users immediately active

The " Active" setting determines if Microsoft Team "Members" are considered as users for Nimbus call distribution. Enabling this feature will automatically add new team members to your Nimbus service team.

An "Active" state has the following effects:

Only "Active" users may receive Nimbus distributed calls. Users may still be part of a team but remain inactive for the team's designated Nimbus Service.
Team Members that are set "Active" at least once in a month will count into statistics of the Nimbus Administration
Active Members are immediately part of the Nimbus task queue distribution according to the set Workflowsand may handle calls for the service team.
They also appear as "Active" in the Dashboard for all other team members.

Good to know

Both Team Owners and Team Members themselves can toggle their "Active" state at any time within either the My Services tab of the personal Nimbus app or the Team Dashboard >"My State" widget.
Toggling this state acts as a quick "gate" to opt-in and -out of multiple Nimbus Services in case you want to balance your personal customer interaction as user and Nimbus capacity per service team.
In addition to the "Active" state the "User Presence" (within Teams) also needs to be in a state that allows for call distribution → see below.

Don't see this setting? Active state toggles do not apply for skill-based services.

Conversations Distribution

Determines call distribution based on user presence state as set in their MS Teams client.

Precondition: Regardless of Microsoft Teams IM presence, a user always needs to be "Active" in the service to receive Nimbus distributed calls → See above.

Setting Effects

On the My Services dashboard a user will be shown in state: "(Not) Available" according to the configuration above:

Notes:

When a user is part of multiple teams and already taking a call for one service line, the user is also marked as " Not Available " in all other Nimbus teams.

IM presence states considered by Nimbus are:

Available
Busy
Do Not Disturb
Away
Offline

Related settings to check

Whenever you make adjustments to your Distribution we also recommend to check the following:

Workflows - as activities inside - such as "Availability-based Routing" or "Queue" will affect call distribution, reaching more or fewer (active) users respectively. MS Teams presence is also re-evaluated depending on the "Distribution Type" setting in the "Queue" workflow activity:

Distribution Type setting	Availability Scenario	Effective Task distribution
Broadcast	When a user turns back to "Available" and a broadcast task is in the queue.	During the next distribution iteration (timeout criteria or decline by other users) the user is included for distribution.
Direct	When a user turns back to "Available " and a direct distribution task is in the queue.	During the next distribution iteration (e.g. RONA criteria or decline by previously selected) this user included for distribution.
Pickup	When user is "Not Available" Pickup controls are disabled (e.g. in Dashboard)	During the next distribution iteration (e.g. RONA timeout) this user included for distribution. A message will be shown on mouse-over that the IM presence is preventing task handling.
None, see node exit ►	No One Available	Currently all users are inactive (or active but set "offline" in MS Teams)
None, see node exit ►	In Time Available	Currently active users are not immediately available e.g. "DND/Away/Busy" or when occupied by another call.
None, see node exit ►	Direct Available	Currently at least 1 user is available = MS Teams presence set "available" and also set to "active" in Nimbus).

Reporting Settings (Settings > General > Reporting ) - as user related distribution and availability changes can directly affect your reporting SLA.

Task Priority

Contact Center Service Type feature. The Task Priority determines how incoming calls from this service are handled in sequential order.

Configurable Property	Description	Behavior	What it looks like
Task Priority	Strict* Highest Very High High Normal (Default for Services) Low Very Low Lowest Nothing Else* * see	When a new task enters the to the queue, it gets a priority according to the service setting: Tasks are distributed according to your currently applied Distribution Policy (e.g. "Longest Idle" or "Most qualified" users first). The order of Tasks is handled by priority, meaning: A new task of higher priority over existing tasks will take precedence and be handled as soon as possible. A new task of equal priority will be sorted in below already existing tasks of the same priority, as it entered the queue at a later point of time. A new task of lower priority will be sorted "in-between" higher priority task rounds, using a weighted round robin method. → See chapter below. When should I select "Strict" or "Nothing Else" as my priority? "Strict Tasks" will always be put on top of your queue. Use this for Emergency services and important VIP hotlines that always should get precedence over anything else in your queue. "Nothing Else" Tasks will only get distributed when your service queue is empty. Note that selecting either "Strict" and "Nothing Else" will ignore round-robin distribution. Tasks get lost due to potentially long queue times.	In views with a task list (e.g. My Overview or Personal Dashboards with "Task" widgets) a "Priority" column indicates how high this task is ranked in the queue. With this setting, tasks may now "displace" existing tasks to a new rank.

Weighted Round Robin Task Distribution

Due to the rules above, task may "starve" for very long in a queue. An example would be a "Lowest" priority task getting outranked by higher priority tasks. To avoid this, a weighted round robin method is in place to mix in lower-priority tasks, equally distributed amonst available users:

Learn more...

_{Q: Calls in Queue | H: Handled | R: Remaining}

Priority	Q	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R	H	R
1 (high)	12	2	10			2	8					2	6			2	4					2	2			2	0
2 (med)	6			1	5			1	4					1	3			1	2					1	1			1	0
3 (low)	3									1	2									1	1									1	0
Round Counter		Round 1				Round 2						Round 3				Round 4						Round 5				Round 6
Time (t)		t₁																													t_n
Weighted Round Robin The Round Robin procedure distributes the calls in such a way that the ratio between the individual priority levels is always 2:1. Each time another "Round" is started, that round counter is applied to the "weight" of the remaining tasks. The example above assumes a configuration with 3 priority levels. There are 21 calls in the queue, with the following priority: 12 calls with priority 1 6 calls with priority 2 3 calls with priority 3 Following the 2:1 rule, the calls are queue over time t as follows: Round 1: High Med tasks added in 2:1 ratio. No "Low" priority tasks in Round 1 as "Medium" task count outweighs the low task count. Round 2: High Med Low tasks added in 2:1 ratio. The "Low" priority tasks get a round-multiplier added to their weight, now outweighing "Medium" tasks and thus are added in a 2:1 ratio. Round 3: Same as Round 1. Sources: Weighted Round Robin (Wikipedia Article). Please note that this example only works as long as no new calls are being processed. Calls with strict or no priority are not considered in this rule.

Task Priority in "Queue" workflow activites

In a multi-service environment, the "Priority" setting effects your "Distribution Type" setting within a Queue Workflow Activity:

Scenario	Setup	Outcome	Learnings
2 Services A&B using a "Broadcast" Queue Activity setting in their Workflows.	Service A : Broadcast, Calling Timeout - 30, priority "Low" Service B: Broadcast, Calling Timeout - 30, priority "High" Both services pool the same 10 users, Active and Available	A first (low) call to Service A will block all 10 users with the call invitation. A second (high) call to Service B enteres the queue. All users are still blocked for the 30s timeout. The first (low) call is declined by 1 user, which then immediately gets the second (high) call distributed. All 9 users are still blocked by the (low) call engagement until it is handled. Only the 1 user finishing the (high) engagement may take the next (high) priority call.	The "Broadcast" Queue setting is fixed to a 10-user batch. In a Priority scenario the first call entering – even if lower priority – may block higher priority tasks.

After Call Work (ACW)

Contact Center Service Type feature. ACW time (in seconds) is added to the end of a call session until the user is considered available again to take the next task.

Option

Description

ACW in Portal UI View

Enable ACW Time

When enabled, shows ACW in both My Sessions and Assistant in the Nimbus portal.

Once enabled the default ACW time (02:30 mm:ss) is granted. Can optionally be extended or stopped with the additional options below.

Allow Early End

Enables all Nimbus users of that service to stop the ACW counter at any time.

→ Stopping ACW will free up the user to become "Available" within Nimbus and receive the next task / call.

Allow Time Extension

Enables all Nimbus users of that service to extend ACW by the amount specified in the " Maximum ACW Extension Time ".

This time is granted as flat "new" value to the user, not added to any remaining ACW time.

Notes on After Call Work (ACW)

When a user goes offline in Microsoft Teams it will terminate the remaining ACW time for that user.
Changing the ACW Toggle / Time in settings during productive hours will have an impact on new (incoming) Tasks only.
Users are blocked from all other Nimbus service calls during ACW.
ACW is also tracked in Power BI for reporting purposes. Reports ACW time in seconds or "Null" if disabled. Total ACW time in a single service session is summed up from all involved user sessions.

RONA

Contact Center Service Type feature. RONA (Redirect On No Answer) is a "not selectable / available" User State for all type of services. A Nimbus user in MS Teams is given RONA status if they ignore a service call or do not answer it within a set period of time seconds.

The RONA status ensures that the call doesn't get lost and is instead redirected back to the queue (or handled otherwise via the Workflow). RONA is also tracked in the Nimbus Reporting Model, and can be evaluated via Power BI OData interface.

This status does not apply when the Distribution Type in your Queue Workflow Activity is set to "Broadcast", as it would otherwise flag entire batches of users with RONA status when a call doesn't reach them.

You can configure RONA as follows:

Element

Description

Persistent RONA
(toggle, default: disabled)

Adds a persistent RONA state to any Contact Center licensed users of that service when they fullfill either of the following criteria:

Decline a call from that service
Ignore a call invitation from that service

While in RONA status the user is considered as "Not selectable / Available" by Nimbus and will not receive further call invitations. → See note below.

RONA Reset Time

RONA Reset Time (must to be specified)

- hh:mm:ss format
- Default 10min
- Min 10 sec to Max 320 min (8h)

RONA Reset Conditions

An already active RONA state can be reset as follows:

Automatically, after the specified "RONA Reset Time"
Manually by the user via Assistant (both portal and standalone). An count-up timer shown next to a manual reset button.
When the user goes Offline in MS Teams.
When the user switches to an "Off Duty" Profile.

Changing the persistent RONA flag to false or changing the reset time will not have an impact on already set RONA states.

Outbound Service Call

The "Outbound Calls" feature allows service members to impersonate and make calls "as" the service itself. This feature is also known as "Call As" or "Call On Behalf". Outbound calls can also be scheduled and added to a service's queue, distributing the task among its available users.

Call on behalf from within the Portal UI

Outbound "Calls on Behalf" can be manually initialized from the Nimbus portal.

Preconditions

Enterprise Routing Contact CenterOutbound Calls are a Enterprise Routing and Contact Center Service Type feature. "Outbound Conversations" must be enabled via Workflow Service Settings for the corresponding service.
Services using this feature need to have a PSTN number assigned in order to dial out to an external number. → Also see "Known limitations" chapter.

Note that Basic IVR Services (User assignment type = None) are excluded from this feature.

To initiate Outbound Service Calls :

Navigate to the My Overview or My Services view and click on the telephone icon next to the service you want to call as.
→ A teams dial out popup opens. You can now dial a number.
Before calling you can still choose between all services which are available to you (and enabled for "Outbound Service").
To start the outbound conversation, click on the "Call" icon .

Call button states and interaction

Nimbus interactions will disable the call button, e.g. when the user has an incoming / connected call or ACW task.
Offline and DND will not disable the button. User related "Busy Available/ Away Available" settings - made via Distribution Service Settings > Conversations Distribution – such as "available when busy" – are also ignored.

Scheduling Outbound Service Calls via Flow

By using the Microsoft Power Automate Connector an administrator can also use the Flow Action > "AddOrUpdateOutboundTask" to schedule outbound calls.

Read the related Use Case - Creating Nimbus outbound calls from a list of scheduled tasks on how to set this up.

Pleae note that the same preconditions and limitations apply for this method.

An Outbound task will show up in Supervision Personal Dashboards and within the " Service Outbound Tasks Tabular" Dashboard Widgets .

Known Limitations

Currently Known Limitations

PSTN Licensing: When the selected Service doesn't have an applied phone number, the dial pad is disabled. Dial out to a UPN is allowed. → Also refer to the "Transfer to PSTN Limitation" below.
UI visibility : "Outbound Service" calls are currently not shown in any UI like My Sessions or Attendant Console - as a result user won't be able to park/transfer/consult/etc.
Reporting visibility: Terminated outbound calls are not reflected on any reporting view (Reporting, Dashboard or Power BI)
O365 Search: In order to retrieve and call to O365 contacts, a tenant admin need to grant "User.Read.All" consent for all Nimbus users, as described on the required user permissions page. We are continously monitoring to adapt and reduce the required rights if possible.

Transfer to PSTN limitation

Out-of-the-box, Nimbus and affiliated addons can only perform PSTN transfers according to Microsoft's licensing and constraints.

Which PSTN license do I need to acquire?

As a tenant administrator you need to acquire the following licenses and assign them to the application instance of the respective Nimbus SOURCE service (team) that will act as PSTN transferor:

Your Setup	Required License
Direct Routing	"Microsoft Teams Phone Resource Account"
Calling Plan	"Microsoft Teams Phone Resource Account" + "Microsoft Teams Domestic Calling Plan" or "Microsoft Teams Domestic and International Calling Plan" or "Microsoft Teams Calling Plan pay-as-you-go" + "Communication Credits" (if these aren't already included as part of your plan)
Operator Connect	"Microsoft Teams Phone Resource Account"
*As of 2023 "Microsoft Teams Phone Standard"* licences are no longer supported by Microsoft*. Previously those licenses were viable for Nimbus. → Regardless if you are using Direct Routing, Calling Plans, Operator Connect* - the "Microsoft Teams Phone Resource Account" license is now always required. Please note that Luware staff cannot make recommendations on which license plan is best suited for your needs. Depending on your scenario, additional Teams App licenses may be required. Exact details are to be discussed with your Microsoft contacts. Also see: https://learn.microsoft.com/en-us/microsoftteams/teams-add-on-licensing/virtual-user

How does PSTN licensing affect Service and Call Transfers?

Assuming that Service A has a PSTN license assigned - but further Services don't - the following scenario may unfold:

Scenario A - Service A workflow is configured to transfer the caller to Service B. The license of Service A is used, the PSTN transfer occurs. The PSTN license is re-used throughout further transfers to Services C..D...x.
Scenario B - Service B is called directly instead. Now the workflow of Service B attempts a redirect to either service A or transfer to C. The PSTN transfer fails due to a missing license on Service B.

Learnings

For one first-level-response Service: If you handle first-response calls always via the same Service you need a PSTN license for that particular first-level Service.
For multiple first-level-response Services: If you handle first-response calls always via multiple Services you need a PSTN license for all those first-level Services .
Nimbus will attempt to use the PSTN license of the first service that responded to a call, regardless of how many further internal service transfers are performed thereafter.
If no PSTN license is found on a service that requires it for a transfer, the transfer task will be considered as failed and be treated as such by the system (e.g. workflow exit announcement, reporting "transfer failed" outcome).

Note that handling and tracking of running cost for PSTN licenses is outside of Luware support scope.
If you require assistance in extending and/or configuring your Nimbus services for PSTN our support will gladly assist you:

Luware Support

Website	https://luware.com/support/
Helpdesk	https://helpdesk.luware.cloud
Service Status	https://status.luware.cloud/

Refer to the external reference: Microsoft Teams PSTN connectivity options and Microsoft Teams add-on licenses.

Context

Allows to configure additional information (context, codes) that may be or provided alongside a service call session.

Enterprise Routing Please note that this is an Enterprise Routing Feature.

Please note that all context items are defined in the Configuration. Some context requires technical expertise and is limited to the Admin backend of Nimbus.

Portal Conversation Context

By adding Context a separate URL (e.g. a CRM or Support-Tool) can be opened in additional browser tab.

Available items must be defined via Conversation Context located within the Configuration. This can be done by service owners themselves

In addition to the My Sessions showing caller information you can define Context to open in a extra tab or widget whenever a Nimbus call is accepted.

Possible use cases for context could be:

Create, update or open incident tickets in your based on incoming call information.
Provide additional help or instructions to your Agents, based on the called services.
Extend the call scenario with further browser-based applications such as CRM, SAP or custom-developed apps.

Before you start, please consider the following points as you are using context in Nimbus:

Context tabs require your opened browser

To open context in tabs during active calls, your Nimbus Personal App must run in your browser.

The Nimbus Teams Tab or MS Teams itself cannot open context by itself.

→ Within MS Teams you can open Nimbus via the " Go to Website" Icon located at the top right of your Nimbus app. Alternatively you can use any of the following links:

_{Portal URLs:}

Switzerland: https://portal.luware.cloud/
Germany: https://portal.dewe-01.luware.cloud/
UK: https://portal.ukso-01.luware.cloud/

Make sure to configure your web proxies to allow access to these domains or whitelist the complete *.luware.cloud domain.

Open Nimbus in Browser

Prevent pop-up blocking

To ensure that this feature works as intended, make sure that Microsoft Teams and Nimbus URLs are excempt from any pop-up blockers.

Your company IT policies, Ad-blocking addons or browser specific settings can also provent opening of context.

Pop-up warning from Microsoft Edge

Assistant Conversation Context

Assistant works standalone App and can also provide context during calls to individual users. As Administrator you can configure the following:

Define (Service or User) specific Call Templates that trigger data requests and can open other local apps or scripts on an incoming call.
Re-use or define specific conversation context context opened as the call is ringing or accepted. By doing so, users do not need tohave

Once Assistant is installed and running in the background of a user's PC, a permanently opened Nimbus browser tab (e.g. My Sessions view) is not required anymore to get call context.

Within a Service you can configure context for Assistant individually as follows. Either option or a combination is possibe:

Audience

What to configure

Description

For individual Users (Agents)

Direct Call Templates

Direct Call Templates are assigned and triggered by Assistant for an individual user, opened in their system-default browser during an incoming direct call.

Direct Call Templates containing the trigger points and actions and must be defined via Administrator-side Configuration first. Once created, Templates can be added to a user via Assistant User Settings.

Our Use Case - Chaining of Assistant requests provides a step-by-step example.

Configuring User-specific context for Assistant

For Services

Service Call Templates

Service Call Templates are assigned and triggered by Assistant during an incoming service call.

Service Call Templates containing the trigger points and actions must be defined via Administrator-side Configuration first. Once created, Templates can be added to a user via Context Service Settings.

Our Use Case - Chaining of Assistant requests provides a step-by-step example.

Configuring Service-wide context for Assistant

Note that the same configured context items can be assigned for Nimbus frontend portal users simultaneously – e.g. while having My Sessions opened in a browser tab already.

Assistant users do not need to have the portal open at all times anymore, as they receive context via the App itself.

Conversation Context

Context is opened by Assistant in the Nimbus users default browser during an incoming service call.

Context items must be defined in the Administrator-side Configuration first to appear as entries to add to a service via Context Service Settings.

Our Use Case - Defining and using Conversation Context provides a step-by-step example on how to configure this.

Codes (Primary, Secondary)

Allows users to specify Primary and Secondary codes to be stored alongside a customer interaction in the My Sessions view. Codes will stored as part of historic reporting and available via Power BI.

The corresponding Widgets need to be enabled in → Extensions tab.

Primary and Secondary Codes must be configured beforehand before they can be added.

Extensions

Manages extension Nimbus Features such as Codes and Conversation Context displayed on the My Sessions overview . Enabled features are immediately available to all Nimbus service team members.

Before you enable extensions

Please note that some extensions will only be fully configurable when you have the according license applied via the Service Administration. Refer to Nimbus Features for an overview and get in contact with your Nimbus sales contact if you require a demonstration.

My Sessions Widgets

Enterprise Routing Contact Center These features require either an Enterprise Routing or Contact Center license on the service.

Widgets are configured for the My Sessions view which provides caller information and context during an ongoing or concluded call.

My Sessions Widget Settings

The following settings can be configured:

Setting	Description
Codes and Tags	Enables a "Codes & Tags" widget in the My Sessions view. Users can click on any conclused session (marked with ) to fill in these interaction details. Note that configured Codes need be available to the respective service's Organization Unit and be appliedin the Context Service Settings in order to be visible as entries in this view.
Contact Search	Enables a "Contact Search" widget in the My Sessions view. During an ongoing call you can perform a search and notify contacts in your Organization.
Conversation Context	Enables a "Conversation Context" widget in the My Sessions view. During an ongoing call this area can open one website based on preconfigured context, for example: A CRM or user database which attempts to retrieve caller information A ticketing system that automatically creates a new entry for each call Any helpful website for lookup, translation, search etc. My Sessions "Conversation Context" showing a website Note that configured Conversation Context needs to be available to the respective service's Organization Unit and be applied in the .Settings vCurrent in order to appear in this widget. Context can be greatly expanded by using the Microsoft Power Automate Connector. Read our related Use Case - Defining and using Conversation Context for a simple hands-on example and check out our List of Use Cases for more inspiration.

Interact

Interact allows customers to directly communicate with your service agents via website, without the need to install or run a chat client on their side.

Preconditions

TENANT ADMIN The tab becomes visible when Interact was enabled in Tenant administration. Once configured Interact allows customers to reach the service directly from external URLs (websites) via small chat or voice widgets.
Contact Center The Contact Center license needs to assigned to a service for the settings to become visible. See Service Administration > General Tab > Licenses.

Editing Interact Service details

After the Service has the according license the Interact-tab will become visible.

The following options can be configured:

Element	Description
Active	When enabled. Current Service is active as a contact for Interact calls. When disabled the service is deactivated as a contact for Interact. Nimbus distributed service calls will still reach the service despite of this setting.
Can be contacted on busy	Determines if outside contact controls are disabled when the service is busy (all users preoccupied with other tasks).
Restrict Access	You need to configure at least one Domain Template CORS for this option to be come available. Interact Domain Templates (CORS) act as "whitelists" When enabled, web page access to this service is limited to domains specified in the CORS templates. When disabled. any web page may access the service.
Domain Template	Lists Interact Domain Templates (CORS) available under the same Organization Units as the current service.
Service Snippet	Default script with settings of current Service, which is later can be inserted into a the web page and used as a contact widget. Please note that the "Contact ID" and "WidgetKey" are unique to the current service and should not be mixed. Use the "Copy" button for easy Snippet Code retrieval.

Learn more about the configuration in our Use Case - Setting up Interact.
Interact features can also be enabled per user. See Interact User Settings .

Agents

Preconditions

Contact Center feature. Contact Center licenses are required on the Service Administration and User Administration.

TENANT ADMIN The "Agents" tab becomes visible when the Service type is set to Contact Center (skill-based distribution) and has Agents / Owners assigned via Service Permissions.

User Skills and Levels need to be configured as assignable items first before they can be assigned to Agents. Refer to our Use Case - Setting up a Contact Center for a full walkthrough.

TEAM OWNER You will see this tab when your service has Contact Center Features enabled and "Agents" assigned.

Services of User assignment type "MS-Teams based" will show the User Service Settings instead.

Editing Agents

TEAM OWNER Any service owner can access the " Agents " tab to adjust the levels of Skills and Responsibilities of Agents assigned to your service.

Active Profile	Acts as the equivalent to the toggle, available in the Assistant app.	Agent changes and their effects Please be aware that profile edits on users have potential widespread effects: Responsibility Profiles of Agents are considered by *any* skill-based service for the distribution: If no skills are assigned or responsibilities change, the user may not be selectable for calls. Changes immediately affect all services that the Agent is assigned to via role / permissions . Skill and duty changes are made on the user itself. They are visible to other admins and service owners with view / edit permissions on this Agent. Distribution Policies set in each service's Settings > Distribution tab will reflect Agent skill and responsibility changes immediately as the next call arrives. *An example for skills / responsibility levels:* An Agent is part of 3 services A, B and C but their skill levels currently allows distribution only according to the Distribution Policy set in service A. You decide to raise that Agent's language proficiency level. → Service B requires that level and will now consider the Agent as well. You do not need the responsibility and decide to deactivate it. → Service C's distribution policy however relies on it and will still not consider the Agent despite the higher skill level. The owner of service C will add a completely new skill to this Agent and reactivates responsibility at the same time. The next time you edit this Agent, can see this change reflected. Important: If you share Agents between multiple team owners, coordinate your changes to their skillsets and responsibilities. Refer to the Distribution Order page for more details.
Edit (Skills / Responsibilites)	Allows adjustment of Skills and Responsibilities for each User.