Luware Knowledge

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

Create Service

Administrators create Nimbus Services in the Admin Portal under Service Administration with the Create New button. This page walks you through the creation and the steps that should follow.

💡 Other ways to create Services, such as directly from Microsoft Teams, are described under Other Ways to Create Services below.

PRECONDITIONS

✅ Permission: You have an Admin Role that is allowed to create Services in the Organization Unit you want to use. Only Organization Units where you have this right are offered in the dialog.

✅ Licenses: A Service license is still available (→ License Management). If no licenses are left, Create New is disabled and shows “No Licenses”. A Nimbus Unify Service additionally uses a Contact Center license.

✅ Service Type choice: 

  • The creation dialog lets you choose between Nimbus Unify and Nimbus Extend services. You can visit our Integration Model Comparison for more details
  • The Service Type Nimbus Unify is only offered when Nimbus Unify is enabled for your tenant. Without it, Create New creates Nimbus Extend Services.

✅ UPN: You know the Service UPN you want to use. It must be valid and not used by another Service.

 

Step by Step: Create a Service

Nimbus Admin: “Create New” Service button and Service Type selection dialog
  1. Open Service Administration in the Admin Portal and select your tenant.
  2. Click Create New.
  3. Choose the Service Type (only if Nimbus Unify is enabled for your tenant): in the Create Service selection, pick Nimbus Extend or Nimbus Unify and click Next. If you are unsure, see Service Types.
  4. Fill in the Service details in the Create Extend Service or Create Unify Service dialog (see the table below).
  5. Click Create.2
Field1 Description
Name Internal name of the Service in Nimbus. Shown in Nimbus lists and settings.
Service Display Name The name that identifies the Service towards callers and users, for example in Microsoft Teams.
Service UPN The address of the Service (e.g. service@yourdomain.com). Must be valid and unique. Nimbus checks this while you type and shows UPN is not unique or UPN is not valid.
Organization Unit

Where the Service is placed. The Organization Unit decides who can see and manage the Service, both from a settings perspective and for related Configuration 

 

1💡All fields can be changed at a later time, but may require another run of the Provisioning via Microsoft PowerShell script.

2☝️ Please note: The creation dialog does not ask for a User Assignment Type. A new Service always starts with the User Assignment Type “None”. You choose it afterwards in the Service Settings (→ After the Creation: Next Steps below).

 

INC Service Fields Length Limitations

🔎Service Fields length validation

When creating or updating a service the API enforces the following character length limitations for the service fields Name, Display Name, and UPN 

  • Name: max. 512 characters
  • Display Name: max. 256 characters
  • UPN: max. 113 characters
    • the UPN must adhere to the following requirements:
      • max. 64 characters before the "@" symbol
      • max. 48 characters after the "@" symbol
 

After the Creation: Next Steps

✅ At this point, the Service exists in Nimbus, but is not operational yet. Work through these steps:

Distribution Service Settings with Users > User Assignment Type dropdown (None / Skill-based)
  1. Choose the User Assignment Type3. In Distribution Service Settings, set Users > User Assignment Type to None or Skill-based (see below). Do this first, because it decides which settings and tabs you will see.
  2. Run the provisioning script. Pending changes to the Service name and UPN become active after the Microsoft PowerShell provisioning steps have been run. This applies to Nimbus Extend and Nimbus Unify Services alike (→ Provisioning via Microsoft PowerShell). Without them the Service is not operable.
  3. Check the General settings. Verify name, Service Display Name and UPN, and optionally add a PSTN number and Opening Hours (→ General Service Settings).
  4. Assign a Workflow. In Modalities Service Settings, select the Workflow that handles incoming calls (→ Workflows).
  5. Optional, Skill-based Services only: Grant Service Permissions to the users who should work in the Service and set a Distribution Policy.  
    🔎 Also see Use Case - Setting Up a Contact Center.
  6. Test. Place a test call to the Service UPN. Once assigned, you can also manually dial the PSTN number to the same effect. 

3🔎 Picking the “User Assignment Type” of a New Service

User Assignment Types

INC User Assignment Types

Each Nimbus Service can be of a different User Assignment Type that determines how Users are associated to this Service:

  • MS Teams-based: Directly tied to the Team itself in MS Teams, determined during Service Provisioning. Users get automatically added and synced to a Nimbus Service.
  • Skill-based: Applies for manually created Services via Nimbus Service Administration. Requires skill-assignment to Users you manually assign to the Service from within your Tenant directory.
  • Direct Call Handling: A service tied to one user with underlying Resource Account account and assigned phone number. Call Forwarding Rules can be defined via Direct Call User Settings or the User's personal Preferences (Portal). Can optionally transfer to individual “Direct Call Handling” type Workflows.
  • None: Primarily used for IVR or first-level redirection Services. This Service has no Users and is therefore primarily configured by any Administrator.

☝ Important to know: The User Assignment Type setting is fixated when a Service was either provisioned via MS Teams or manually created via Service Administration, e.g. either for Customer IVR or User skill-based task distribution purposes. A switch between MS Teams-based and Skill-based Services is not possible due to how individual Users are configured and how related Nimbus Features operate.

 

🤔 Is the User Assignment Type tied to the Service Type / License?

Indirectly, yes. While User Assignment itself is not technically bound to Service Types and related Nimbus Features, User permission handling and Nimbus Task distribution underlies technical restrictions, primarily dictated by how MS Teams handles its channels and roles.

User Assignment Advanced Routing

Enterprise Routing

Contact Center

 Description
MS Teams-based  ✅ ✅ 🔍 Relevant if you want to stick to MS Teams-based User sync but use Contact Center  Features  MS Teams-based User assignment is the most common scenario for new Advanced Routing and Enterprise Routing licensed Services. Nimbus Portal Roles are automatically inherited from the role in the MS Teams channel, minimizing the administrative effort to onboard and configure new Users.
Skill-based1 ❌ ❌ ✅

The main use case for Contact Center Services is setting up Distribution Policies to escalate calls based on Skills and Responsibilities.

The Distribution Order guarantees that Users get selected in a very targeted manner.

With adjustments of their skills and Duty Profiles Users can opt-in or out of certain distribution policies, e.g. based on time of day, workload, current responsibilities.

Adding and removing of Users is very flexible, e.g. across departments and even outside of any MS Team-based constraints.
None1 ✅ ✅ ✅ Services with User assignment type "none" are generally used for IVR or automated redirection. They can be created manually and outside of MS Teams channel restrictions.

Switching between User Assignment Types

1 Switching the User Assignment Type is possible outside of MS Teams-based context. For example, you can convert a “Skill-based” Service to type “None”, e.g. when you decide to delegate Users to different Services. 

☝However, before doing so, please note the following effects:

  • When switching User Assignment Type to “None”, all previous Settings made within the Service Distribution Tab are discarded and will be at their defaults, should you decide to switch back.
  • On “None” User Assignment Type setting, Workflows configured in the Modalities Tab will show warnings. Activities that involve any task distribution to Users (e.g. “Queue”) will automatically be skipped over. This may result in error scenarios during an incoming call. 
    → We therefore highly recommend checking your Workflows right after converting your Service's User Assignment Type.
 
 
 

🤔 How does the User Assignment Type affect my Service operation?

The User Assignment Type greatly determines how the Service (and Users) are managed. This also determines, which Features and Data are available to Users, and how granular the Role-based Access Concept (RBAC) can be implemented by Administrators.

💡 MSTeams-based Services are tied to the Team itself, but not to a particular channel within that team. 

  • The Service name and all channel Users are in sync with and actively used by Nimbus for task distribution. You can select one specific public channel to which the Service will post Adaptive Cards for Voicemails or call pick-up notifications.
  • Other than that, Nimbus will not impact other channels or functionality. You can "add" the Nimbus app tab to every available channel of a Team, if you want, but it will always only display the same Team statistics.
  • Very simple User Management with a fixed set of Portal Roles that grant access to Nimbus functionality.

💡 Skill-based Services allow Users to participate in multiple Services simultaneously.

  • The individual Services are NOT tied to using MS Teams channels as central point of communication and User management. 
    • The removal of a dedicated Teams channel also removes the possibility for a single channel for Voicemails, as it would cause data access and GDPR compliance risks.
  • Skill-based Services add flexibility, but also complexity:
    • Users on skill-based Services are managed via Agent Service Settings per Service. This can be done by any Team Owner.
    • Optionally Users can get Skills and Responsibilities assigned for escalated Service task distribution. A Distribution Policy assigned to each Service determines how new incoming tasks are distributed among Users, depending on their responsibility and expertise.
    • Allows to expand the Portal Roles with additional Supervisors and/or preferred Users.
    • 💡 Good to know: Users are also not "Active" on skill-based Services per default. Instead, they control their own Service availability via configurable Responsibility Profiles.

💡None - Services with no Users assigned: 

  • These Services do not have Users nor a specific MS Teams channel, and therefore don't use most of the abovementioned features. They only act as “gateway”, e.g. to route customers to actual Services via IVR.
 
 

🤔 Does the User Assignment Type affect available Features?

Yes, because certain features cannot operate “outside” of a given MS Teams context in order to steer User access to Service data and functionality. 
Here are some examples on how various features differ based on User Assignment Type:

Feature Feature MS Teams based Skill- based None
Workflow configuration Adaptive Cards ✅ - -
Voicemails ✅ - -
Service Settings Configurable Voicemail channel ✅ - -
Extensions tab ✅ ✅ -
Conversations Distribution ✅ ✅ -
Setting of a Distribution Policy - ✅ -
(New) User “Active” settings ✅ - -
Reporting section ✅ ✅ -
Editable "Name" field on Service Settings - ✅ ✅
Frontend UI "Active" toggle for Users ✅ - -
Users switching Service availability via Duty States / Responsibility Profiles  - ✅ -
 
 
 

Other Ways to Create Services

Way How it works Result
Directly in Microsoft Teams Add the Nimbus app to a Microsoft Teams team and complete the setup in the Nimbus tab. Details, prerequisites and the provisioning script: Service Provisioning. Nimbus Extend Service with the User Assignment Type MS Teams-based.
Nimbus API Services can also be created via the Nimbus API with the Create Service method (role Provisioning.Service.Create). An existing Service can also be copied with the Copy Service method. Service with the User Assignment Type None; a copy creates a skill-based Service with the licenses and configuration of its source. Needs a free Service license, otherwise the request fails (403).
From a user (Direct Call Handling) Set up from the user’s Direct Call tab in User Administration (→ Direct Call Handling, Direct Call User Settings). Service of the Service Type Direct Call, licensed per user.
 
Delete Service

Services can be deleted either manually via the Administration UI or via Nimbus A...

Service Administration

The " Services" view allows administrators to manage, edit and remove existing te...

User Assignment Types

INC User Assignment Types Each Nimbus Service can be of a different User assignme...

Service Provisioning

Prerequirements ☝The Nimbus Installation must be completed (and the Nimbus App ma...

Table of Contents