Luware Knowledge

Nimbus Portal Nimbus Admin Release Notes Service Status
Home Nimbus Administration Bulk Editing

Bulk Editing

Changing Nimbus settings on a larger scale

Bulk Editing allows you to make comprehensive changes on multiple data entities within the Nimbus Service Administration and User Administration. This feature will allow any User with Nimbus Administrators role to: 

  • … compare multiple entries and their settings, highlighting differences.
  • … standardize licenses, related features and settings.
  • … review the changes in post, using the Bulk Operation Overview.

Before You Start

Licensing Constraints

Same as in single editing, Bulk Editing allows to apply licenses and thus enable (or remove) features per User or Service. Refer to Nimbus Features for a comprehensive overview, and check on your License Management view to ensure you have sufficient licenses to bulk-apply.

☝This feature is quite powerful, but also allows you to make sweeping changes that may undo prior work in User configuration. Please ensure to read the following chapters thoroughly to understand all the concepts. 

🔎Also refer to our Best Practices - Bulk Editing for tips and considerations.

 

INC Bulk Editing Limitations

KNOWN BULK EDITING LIMITATIONS INC Beta Feature This feature is in BETA status. F

KNOWN LIMITATIONS - BULK EDITING

INC Beta Feature

This feature is in BETA status. Functionality, design, and scope may change significantly over time.

Bulk Editing is in Beta stage and underlies technical limitations and UI design constraints. We will update this note continuously as we improve the feature during its Beta design stages. 

☝ Please read the following limitation topics carefully to understand where the limitations lie. We also continuously update our Latest Release Notes whenever changes and improvements to this feature will be made.

🤔 Which features are available for Bulk Editing?

Bulk Editing - Services and Users only: This feature is currently intended to allow only service and user bulk editing. Further configuration entities will be made available at a later date.

Entity What can be changed in Bulk What can't be changed in Bulk
Users
Services

1 Changing User “Services” and “Roles” tabs are disabled during Bulk Editing. Changing roles would have large-scale implications on the existing Service Provisioning and User Assignment Types in Nimbus.

2 Changing these Service options in bulk would require simultaneous work on related and dependent Configuration entities.

3 Addon licenses can be (un)assigned in bulk - same as via License Management. However, each service needs to be individually configured, as the related Settings tabs are not yet supported in Bulk Edit.

4 Must remain unique for the selected entities during bulk edit, e.g. due to a Service being fixed/synched to a "MS Teams-based" channel.

 
 

🤔 What (intended) design limitations are there?

💡By design: Listed below are active design decisions, please do not report these as issues.

☝ No Undo Option - Bulk editing does NOT provide any way of undoing your changes. We recommend making small changes at first to see the effects.

  • Maximum 25 entities can be edited at the same time. 
    • If the total number in a list is larger than 25, “Select All”  is disabled.
    • You can filter your entries below this threshold to apply changes.
  • No bulk creation/deletion  - While in bulk edit mode, entities cannot be mass created or deleted (as a precaution).
  • Dependent change confirm - Certain features rely on dependencies (e.g. an applied change showing additional feature tabs). For this reason you need you to confirm pending tab changes first before applying further bulk changes.

💡Known Limitations: (technical limitations and issues that we already know about.)

  • “Disappearing” Details view - Confirming a bulk change via tab change shows a saving dialog as intended. However, the “Details” inspection feature was only visible on the previous tab bottom and thus cannot be shown on the new tab.
  • Limited Bulk Operation view - The “Details” of bulk operations - next to the “Save & Apply” button - only show a complete set of changes, not the delta changes.
 
 

🤔 Other things to consider?

With this change, it will be possible to modify Organization Units of many entities (e.g. users) simultaneously. ☝ This will inevitably create “Non-Path References” (NPR) warnings in your UI.

What does Non-Path Reference mean?

A Non-Path Reference (NPR) is signaled with a small warning icon in the UI, indicating that “Reading along the path / up to the root” rules were violated with a prior Organization Units change on an entity.

Items with a NPR flag can only be removed, as the OU reference is now violating the “reading along the path” rule of Organization Units.

🤔What is an entity? Anything configured within Nimbus that has its own OU - users, services, workflows, profiles, etc. 

🤔Is there a risk to creating NPRs? Your existing Nimbus references (and related services) will continue to operate even with NPR warnings, but the changed entity (e.g. a OU-moved user) will not be visible for selection anymore once removed. All existing dependent entities (e.g. a service defining an “NPR” flagged user) will still consider this user for tasks distribution as long as the user itself is not actively removed from the configuration.

 
 
 
 

🔎 Related Best Practices: We also recommend reading our Best Practices - Bulk Editing for tips and tricks as well as considerations before engaging with this feature. We will continuously update the page alongside with these known limitations.

 

How to Start Bulk Editing

To start Bulk Editing, perform the following steps:

  1. Depending on if you want to edit Users or Services, go to User Administration / Service Administration respectively and select at least one entity via the checkbox on the left side of the display name. 💡In the example below we show Users, the same method applies for Services.
    ⮑ The “Bulk Edit” Popup window is shown near your selection.

    ⮑ You can now select more entries via their checkbox, or by clicking into the rows.
  2. Use the search or filters to narrow down your choices. 
    ⮑ Your already selected entries (even those outside of the filter or search view) remain selected.
    ☝Note that “Select all” is not an option if your choice would exceed 25 entries. Refer to the → Bulk Editing Limitations for more details.
  3.  Once satisfied with your selection, click on “Bulk Edit” to start editing all the entries.
    ⮑ The bulk edit process will always start on the General tab.
Example: Bulk Editing multiple selected Users. You start with a checkbox (2), narrow down with filters and search (2) and finally start “Bulk Editing” (3)

Simultaneous Editing

Good to know: When two or more administrators are editing the same Users, a banner will be shown informing that the User is part of an ongoing bulk operation.

⮑ In such cases you will be informed once the bulk operation is complete. Once complete the banner will contain a refresh option to ensure you are working with the latest information.

 

Bulk Editing Users 

Bulk Editing Users

💡Select a tab below to learn more about the various User Bulk Editing concepts. 

🔎Note that certain tabs may not available during Bulk Editing. Refer to the Bulk Editing chapters “Preconditions” and “Known Limitations” for more details

 

General Tab / Licensing

As the General User Settings always mark the starting point for Bulk Editing, we will use this view to explain a few concepts:

  • Different (yellow) and equal (green) setting properties are shown color coded.
  • Read only (grey) properties cannot be changed in bulk-mode.💡Note that this also affects some tabs, with reasons provided in info-tooltips. 
During Bulk Editing, different and equal (matching) settings are highlighted.

OU Changes and Non-Path References

☝When changing Organization Units of users in bulk, you may generate NPR (non-path reference) warnings. In a nutshell: NPR are an “exception from the rule” indicator, showing that OU rules are broken. This means:

  • Any existing data references stay intact and services can continue operation.
  • However, other Nimbus users may not find the moved user anymore in their search due to the changed OU.

💡As a more practical example we also cover this topic in the Skills tab chapter below.

🔎Learn more about NPR….

An excerpt from our Organization Units page:

INC Non-Path Reference

In a normal path-dependent scenario, access to entities is strictly governed by t

In a normal path-dependent scenario, access to entities is strictly governed by the OU structure. If a (referenced) entity is moved in the tree (e.g., from one Organization Unit to another), their new position determines access rights:

  • OUs below the new location gain access.
  • OUs (lower in the tree) that were previously accessing the entity lose access, unless the new location is up in the same tree.
  • The moved entity loses access to (referenced) entities that belong to the pervious location, but gains access to the new location's entities.
The OU Access Concept of "reading up the path": OUs can access resources from higher-level OUs but not from lower-level OUs.

In a non-path reference scenario, which is the case in Nimbus, certain OUs and entities can still access referenced/assigned entities even after the they have been moved in the tree structure:

  • For a OU/entity to retain access rights to (referenced) entities, the OU/entity has to use them or have them assigned.
  • Changes in the referenced entity take immediate effect for the entity that is using it.
  • If an entity with non-path reference is removed from the OU/entity, they cannot access it anymore.

💡 This is essentially a kind of "legacy access". So, even if an entity is now in a location where it shouldn't be accessible or have access to entities in the pervious OU, it still is accessible/has access until it is actively removed/stops using them. 

Scenario 1: Moving a referenced entity to another OU

This scenario applies when you move referenced entities (that are used in / assigned to other entities) to another OU:

Let's assume the following OU structure:

In this configuration,

  • OU A, OU A1 and OU A2 have access to Entity 02, Entity 03, and Entity 01.
  • OU B, OU B1 and OU B2 have access to Entity 04, Entity 05 and Entity 01.
  • Entity 04 in OU B is using Entity 05 (e.g. a playlist), but OU B2 is not using it.

If we now move Entity 05 to OU A, the following access rules changes apply:

  • Non-path reference: Entity 04 in OU B keeps access to Entity 05 as long as it is using it or until Entity 05 is removed.
  • OU B and OU B2 lose access to Entity 05.
  • OU A, OU A1, and OU A2 gain access to Entity 05.
Entity 04 in OU B retains access to Entity 05 as long as it is using  it or Entity 05 is removed.

 

Examples

  • Moving Playlists, Parameters to the new OU that are used in a Workflow in the old OU.
    • The workflow using the playlists and parameters retains access to them.
  • Moving Opening Hours to the new OU that are used by Services in the old OU.
    • The service using the opening hours retains access to them.
  • Moving Services to the new OU that are defined as a target in Workflows in the old OU.
    • The workflow having the service as a target retains access to it.

Scenario 2: Moving an entity that is referencing other entities to another OU

This scenario applies when you move an entity that is using other entities or has them assigned.

Let's assume the same OU structure as in scenario 1. This time, we move Entity 04 (which uses Entity 05) to OU A:

In this scenario, the following access rules changes apply:

  • Non-path reference: Entity 04 in OU A keeps access to Entity 05 as long as it is using it or until Entity 05 is removed.
  • OU B, OU B1, and OU B2 lose access to Entity 04.
  • OU A, OU A1 and OU A2 gain access to Entity 04.

Examples

  • Moving a Workflow to the new OU that is using Playlists or Parameters from the old OU.
    • The workflow retains access to the used playlists or parameters.
  • Moving Services to the new OU that is using Workflows or Opening Hours from the old OU.
    • The service retains access to the used workflows or opening hours.

💡Note that the list of examples is not comprehensive. There are numerous cases depending on your configuration. Also note that scenario 1 and scenario 2 might occur at the same time, e.g. when moving a workflow that is used by a service and is having a service configured as target. 

 
 
 

LEARNINGS: Licensing effects

Let's explore Bulk Editing in the context of License Management. In the example above, there are several matching but also different entries.

🔄Licensing changes and (in)visible effects

Bulk License Changes

As you change licenses on the General tab of either Users/Services, there are some effects you should be aware of:

💡Visible effects

  • During Bulk Editing, as you add or remove users/services to edit, the property border colors change depending on the (mis)matching feature set. Clicking a property will change the color, e.g. from “Different (orange)” → “Equal (green)” → “Disabled (grey)”.
  • As you made any changes on properties the the "Save" button becomes enabled. Saving changes is required before changing tabs, also because license changes has background effects (→ see below).
  • After a license change is applied, Feature tabs become visible or are removed. On a mismatch between users, a tooltip will inform why tabs are greyed out, e.g. because licenses are missing for one user.

💡Background effects 

  • Removing licenses works the same way as a License Downgrade. A removed license takes immediate effect (see note below) and can be assigned to other users / services.
  • Adding licenses in bulk checks if your License Management has enough spare licenses to apply to all your selected users. A tooltip will inform when insufficient licenses are available.

☝Important Note: the configuration reset from a license removal is irreversible. Removing a license - either single or in bulk - also removes any previously configured Nimbus Features and related UI tabs and functionality from a User or Service as soon as you Save & Apply your license changes.

→ Double check that you Bulk Edit the correct users as you make comprehensive license changes.

 
 
 
 
 
 

Skills Tab

✅Precondition: Users all must have a Contact Center license.

While Bulk Editing Skills for your users, knowing the Organization Units (OU) concept is essential. Both skills and users are placed in the OU tree. As you select multiple users for Bulk Editing, Nimbus will check the individual users position in the OU tree, and form a cut quantity of skills available to all of them. 

This will lead to the following color codes:

  • A equal (green) skill is available and already applied for all selected users. You can remove it if needed.
  • A different (yellow) skill can be added to all users IF their OU allows to “see” that skill (OU reading along the path rule). Otherwise the skill will be marked with a “Non-path reference” warning → See Learnings below.
  • Read-only (grey) skills should not exist in this view.
Skills placed in lower level OUs may not be added as they would generate a Non-Path References (NPR)

💡By design: Skill level adjustment “per-user” outside of Bulk Edit

While Skills and Responsibilities can be added in bulk, their adjustable levels remain individual per user. This is due to the fact skills skills of the same “type” can still have levels enabled that may be user-specific (e.g. based on call scenario, service called or performance expectancy of that user).

✅ Recommended follow-up steps: 

  • After Bulk Editing skills on multiple users, coordinate with other (OU) Admins to access the → User Administration > Skills User Settings to check the level adjustments on those skills.
  • Also don't forget that new skills must be part of your service's Distribution Policies to be considered for task distribution.
 

LEARNINGS: Organization Units and Non-path References

Skills are a great Bulk Editing example to explain Organization Units. Let's assume you have a set of “regional” skills like a specific language proficiency or category for “generic” skills such as “Being a good listener”:

  • Regional skills, e.g. “German language" (or sentiment, local needs) knowledge, may only be important for your European service division, so the skill may be placed in a Organization Unit “Service Team Europe”. 
  • Generic skills like “Good listener” are not applicable for one particular service, so you make it available tenant-wide (on your highest tenant level OU).

💡Outcome: If two users from different teams (and their specific OUs) are being bulk edited, both might access the “Generic” skill, but only one user may see the “European” regional skill as they are also in OU “Service Team Europe”. Another user - e.g. placed in OU “Service Team America” - would be excluded from accessing "European" skillsets.

☝Important: When changing user Organization Units in bulk, you may generate a lot of these NPR warnings. 

🤔What are Non-path Reference warnings (NPR)?

In short, Nimbus is warning you that a configured entity (in this case: a skill) is not accessible to all your selected users. This may also be the case when the skill itself was moved to a different OU. Existing users still have access to this (moved) skill, even though they shouldn't have it anymore. 

💡Learning: Skills (same as other selectable entities in the UI) with NPR warnings can only be removed.

 
 

🤔How can I resolve skill NPR warnings?

Regardless of what entity you edit (Users, Services, Workflows), they all are assigned to one Organization Unit. Any change in that OU placement may break the reading rule and generate a warning. To resolve this issue, you can: 

  • Place a skill higher in the OU tree, so that more users can access it.
  • Rethink your OU tree, e.g. having a common OU for all your shared service resources. 

💡Learning: Changing the OU of to entities referring each other can cause an NPR warning.

 
 

✅ Follow-Up: When changing Skills in bulk, don't forget that a Portal user (e.g. the team owner) needs to assign skill levels for these users. This is done in Skills User Settings 

 
 
 

Profiles

✅Precondition: Users all must have a Contact Center license.

Responsibility Profiles - as part as the Contact Center feature - can also be managed in Bulk. We'll explain how you can approach this with the following example steps:

  1. Inspect Profile differences - Multiple users may use the same profiles, shown in regular font. Differences in profiles are are greyed out. Here you can observe additional details:
    1. 💡Different Columns (yellow) - When profiles already exist on all selected users, differences are highlighted in yellow.
    2. 💡Inactive Add/Delete buttons - Keep in mind that each one “Duty” and “Off Duty” profile comes as a default which cannot be deleted from a user.
  2. Equalize missing profiles - A profile hat is available to one User A can be added to a User B via the Add-button in the corresponding column.
    1. 💡Note that more profiles get listed as you select more users.
    2. 💡You can also add entire new profiles via the “Add” button on the column top.
  3. Equalize profile settings - Columns for “Default” and “Active” can be adjusted once profiles are added to all users.
    1. 💡You can individually equalize the columns “Default” and “Active” or keep their differences.
    2. 💡Settings from greyed out “Different” profiles will not be affected. 
 
 

N/A Reasons

✅Precondition: Users all must have a Contact Center license.

Not Available Reasons (NAR) are configurable Nimbus Features reasons that users can select in Nimbus portal when being unavailable for calls. During Bulk Editing, the NAR listed in the UI are applied for all users in the order specified. It is important to note: 

  • Feature difference (yellow toggle): If NAR were never enabled for one or multiple users, the toggle is shown in yellow. 
    You need to confirm enabling this feature via toggle first before you can continue editing.

    ⮑The NAR toggle will now turn green to signal that you enabled and configure NAR for all users.
  • Feature equal, but reasons mismatching (yellow reasons): If NAR were already enabled for users, but the NAR reasons mismatch, the FIRST selected user for Bulk Editing acts as template for the amount and order of NAR. 
    You need to confirm the current NAR choice and order via “Apply to All”  first before you can make further changes on their ordering.
    ⮑ The NAR section border will turn green to signal that your NAR choice is now applied. 
Clicking “Apply to All” will confirm the currently applied order of NAR for all selected users

LEARNINGS: Not Available Reasons

  • Enabling Not Available Reasons is a 2-staged process, the feature itself and the actual NAR items with their ordering.
  • The first user with already enabled NAR acts as “template” for other users. 

💡Good to know: In either case you can still review and confirm your choice with “Save”, so make adjustments as you need. → As you save your choice all users get the NAR applied in their Nimbus Portal immediately.

 
 
 

Interact

✅Precondition: Users all must have an Interact license. If users have an Interact license, but not enabled yet, the toggle may appear yellow.  

Orange toggle indicating that Interact is not yet enabled for all users

Once active, Bulk Editing Interact features can adjusted and are indicated using color codes:

  • A equal (green) setting is indicated green underlined. Note that a toggle can be “Inactive” but still underlined green to showcase that this setting applies for all users.
  • A different (yellow) setting indicates differences in this setting. 
    • You can accept this state to not change anything for your users OR click the toggle to change it for every user.
    • 💡 A note on different Interact Domain Templates (CORS): These templates whitelist domains that are allowed to contact this user via Interact. If you are uncertain if all users should use the same template, leave the “Restrict Access” setting as-is and read Use Case - Setting Up Interact first. 
Managing different Interact Settings. Note that User Snippets are individual and thus cannot be managed while Bulk Editing.
 
 

Assistant

✅Precondition: Users all must have an Assistant license. 

Once active, Bulk Editing Assistant features - primarily Direct Call Templates - can be adjusted and are indicated using color codes:

  • A equal (green) border indicates that templates and their order of execution is matching among all users.
  • A different (yellow) setting indicates differences in applied templates.
    You need to confirm the current Direct Call Templates choice and order via “Apply to All”  first before you can make further changes on their ordering.
    ⮑ The section border will turn green to signal that your Template choice is now applied to all users.
A yellow border indicates that the templates are different among the selected users.
 
 

 

Bulk Editing Services

Bulk Editing Services

💡Select a tab below to learn more about the various Service Bulk Editing concepts. 

🔎Notes 

  • Certain tabs may not be available during Bulk Editing. Refer to the Bulk Editing chapters “Preconditions” and “Known Limitations” for more details.
  • Also note that Services with different License levels applied cannot be edited in Bulk Mode.
    ⮑ Checkboxes of incompatible services will be greyed out with a tooltip as you select either Service Type. Refer to License Management and License Downgrade on how to bring them to the same level.
💡Tip: Use the License filter in conjunction with the search to easily Bulk Edit Services of the same type. 
 

General Tab

General Tab

As the General Service Settings always mark the starting point for Bulk Editing, we will use this view to explain a few concepts:

  • Different (yellow) and equal (green) setting properties are shown color coded.
  • Read only (grey) properties cannot be changed in bulk-mode.💡Note that this also affects some tabs, with reasons provided in info-tooltips. 
Example screenshot: Tooltip on tabs, different and equal properties outlined.

On the general service settings you may change non-unique properties of services such as: 

OU Changes and Non-Path References

☝When changing Organization Units of services in bulk, you may generate NPR (non-path reference) warnings. In a nutshell: NPR are an “exception from the rule” indicator, showing that OU rules are broken. This means:

  • Any existing data references stay intact and services can continue operation.
  • However, other Nimbus users may not find the moved entity anymore in their search due to the changed OU.

💡As a more practical example we also cover this topic in the “Modalities Tab” chapter below.

🔎Learn more about NPR….

An excerpt from our Organization Units page:

INC Non-Path Reference

In a normal path-dependent scenario, access to entities is strictly governed by t

In a normal path-dependent scenario, access to entities is strictly governed by the OU structure. If a (referenced) entity is moved in the tree (e.g., from one Organization Unit to another), their new position determines access rights:

  • OUs below the new location gain access.
  • OUs (lower in the tree) that were previously accessing the entity lose access, unless the new location is up in the same tree.
  • The moved entity loses access to (referenced) entities that belong to the pervious location, but gains access to the new location's entities.
The OU Access Concept of "reading up the path": OUs can access resources from higher-level OUs but not from lower-level OUs.

In a non-path reference scenario, which is the case in Nimbus, certain OUs and entities can still access referenced/assigned entities even after the they have been moved in the tree structure:

  • For a OU/entity to retain access rights to (referenced) entities, the OU/entity has to use them or have them assigned.
  • Changes in the referenced entity take immediate effect for the entity that is using it.
  • If an entity with non-path reference is removed from the OU/entity, they cannot access it anymore.

💡 This is essentially a kind of "legacy access". So, even if an entity is now in a location where it shouldn't be accessible or have access to entities in the pervious OU, it still is accessible/has access until it is actively removed/stops using them. 

Scenario 1: Moving a referenced entity to another OU

This scenario applies when you move referenced entities (that are used in / assigned to other entities) to another OU:

Let's assume the following OU structure:

In this configuration,

  • OU A, OU A1 and OU A2 have access to Entity 02, Entity 03, and Entity 01.
  • OU B, OU B1 and OU B2 have access to Entity 04, Entity 05 and Entity 01.
  • Entity 04 in OU B is using Entity 05 (e.g. a playlist), but OU B2 is not using it.

If we now move Entity 05 to OU A, the following access rules changes apply:

  • Non-path reference: Entity 04 in OU B keeps access to Entity 05 as long as it is using it or until Entity 05 is removed.
  • OU B and OU B2 lose access to Entity 05.
  • OU A, OU A1, and OU A2 gain access to Entity 05.
Entity 04 in OU B retains access to Entity 05 as long as it is using  it or Entity 05 is removed.

 

Examples

  • Moving Playlists, Parameters to the new OU that are used in a Workflow in the old OU.
    • The workflow using the playlists and parameters retains access to them.
  • Moving Opening Hours to the new OU that are used by Services in the old OU.
    • The service using the opening hours retains access to them.
  • Moving Services to the new OU that are defined as a target in Workflows in the old OU.
    • The workflow having the service as a target retains access to it.

Scenario 2: Moving an entity that is referencing other entities to another OU

This scenario applies when you move an entity that is using other entities or has them assigned.

Let's assume the same OU structure as in scenario 1. This time, we move Entity 04 (which uses Entity 05) to OU A:

In this scenario, the following access rules changes apply:

  • Non-path reference: Entity 04 in OU A keeps access to Entity 05 as long as it is using it or until Entity 05 is removed.
  • OU B, OU B1, and OU B2 lose access to Entity 04.
  • OU A, OU A1 and OU A2 gain access to Entity 04.

Examples

  • Moving a Workflow to the new OU that is using Playlists or Parameters from the old OU.
    • The workflow retains access to the used playlists or parameters.
  • Moving Services to the new OU that is using Workflows or Opening Hours from the old OU.
    • The service retains access to the used workflows or opening hours.

💡Note that the list of examples is not comprehensive. There are numerous cases depending on your configuration. Also note that scenario 1 and scenario 2 might occur at the same time, e.g. when moving a workflow that is used by a service and is having a service configured as target. 

 
 
 

LEARNINGS: Licensing effects

Let's explore Bulk Editing in the context of License Management. In the example above, there are several matching but also different entries.

🔄Licensing changes and (in)visible effects

Bulk License Changes

As you change licenses on the General tab of either Users/Services, there are some effects you should be aware of:

💡Visible effects

  • During Bulk Editing, as you add or remove users/services to edit, the property border colors change depending on the (mis)matching feature set. Clicking a property will change the color, e.g. from “Different (orange)” → “Equal (green)” → “Disabled (grey)”.
  • As you made any changes on properties the the "Save" button becomes enabled. Saving changes is required before changing tabs, also because license changes has background effects (→ see below).
  • After a license change is applied, Feature tabs become visible or are removed. On a mismatch between users, a tooltip will inform why tabs are greyed out, e.g. because licenses are missing for one user.

💡Background effects 

  • Removing licenses works the same way as a License Downgrade. A removed license takes immediate effect (see note below) and can be assigned to other users / services.
  • Adding licenses in bulk checks if your License Management has enough spare licenses to apply to all your selected users. A tooltip will inform when insufficient licenses are available.

☝Important Note: the configuration reset from a license removal is irreversible. Removing a license - either single or in bulk - also removes any previously configured Nimbus Features and related UI tabs and functionality from a User or Service as soon as you Save & Apply your license changes.

→ Double check that you Bulk Edit the correct users as you make comprehensive license changes.

 
 
 
 
 
 

Modalities Tab

Modalities Tab

✅Precondition: All services will have Audio/Video modalities, Enterprise and Contact Center services have access to Instant Messaging, Email and External Task modalities. Note that you can only configure the specific modality for all services when checked (equal, green).

Note that you can make adjustments for all modalities before saving. Certain properties are protected against change, as they are Service-specific.

Color Coding

Depending on the services and modalities selected, settings will be compared by Nimbus, leading to the following color codes:

  • An equal (green) modality is available and already applied for all selected services. 
  • A different (yellow) modality signals a mismatch in settings. Enabling it will allow you to match the settings for all selected services, e.g. by setting Workflows for that respective modality.
  • A deselected (grey) modality was not applied to either service. You may immediately apply it and configure the properties further below.

OU Workflow visibility

Selecting workflows follows the same Organization Units “reading along the path” rules as any other data entity. Effectively this means that the combination (intersection) of the respective service's OUs determines which workflows are available.

Show me an example…

💡Example Scenario:

You have the Tenant Level OU and two Organization Units A and B defined.

You have two services under OU A and two services on OU B. 

You have one workflow on Tenant level and one workflow on OU B. 

💡Outcome:

In Bulk Edit, both OU A services will only get the Tenant Level workflow to select, as they have no own workflows.

In Bulk Edit, both OU B services will get their own OU B workflow and the Tenant level workflow.

If you now select a service from A and B this will result in an OU-intersection check, meaning that overall ONLY the tenant level workflow will be selectable, as the Service A is the smallest common denominator.

 
 

Workflow activity mismatch

Depending on the selected Service Types there are certain Workflow Activities that will not be compatible. For example, a workflow using a “Voice Message" activity will not be compatible while editing Contact Center services, as these services work standalone and do not necessarily tie into a MS Teams channel. In such cases you either need to: 

Incompatible Workflow warning during Bulk Editing

Learnings: Workflow compatibility checks

  • Services reference other data entities (Workflows, Users, Opening Hours) by following the Organization Units rules - same as any data entity in Nimbus. Your service selection always forms the smallest common denominator to follow the “reading along the path” OU rule.
  • While Bulk Editing services you should know about supported Modalities in Nimbus. All modalities have individual Workflows, each with their own set of modality-compatible Workflow Activities.
  • Workflows may be incompatible between different Service Types. For a comprehensive list of (in)compatible workflow features, refer to Workflow Activities Overview which contains a comparison of available activities.
 
 
 

Inspecting Bulk Operation Details

Bulk Operation Overview

Whenever you save your changes during Bulk Edit, the bottom footer in the UI will show Details which can be clicked on.

Details are shown after saving your Bulk Editing changes.

⮑ A click opens the “Bulk Operation” window that reveals:

  • … the entities (Users, Services) that were modified.
  • … the property (e.g. License, Organization Unit) that was changed
  • … the value written on that property. 💡Note that this shows the new full value set, not a delta from the previous values.
  • … the result of that operation on the individual data entity. 💡More about this in the "Troubleshooting" section → below.
You can inspect changes made on each entry (1) individually. The changeset (2) can also be downloaded as a JSON file on the top right.

All bulk operations are summarized and listed in the Change History 

 

Example JSON Output

💡 Note that the entire (JSON) value set stored by Nimbus is shown here, including not only your changes, but also already enabled properties. An example showing all written values looks as follows - in this example for a User:

{
    "operationId": "ddb67970-ca48-411a-af5d-846185432309",
    "requesterName": "Ada Lovelace",
    "status": "Successful",
    "errorCount": 0,
    "timestamp": "11/08/2024, 9:30 AM",
    "users": [
        {
            "id": "f319e87a-b982-43b0-a904-78e04e084552",
            "displayName": "Scientist Leonardo da Vinci",
            "properties": [
                {
                    "propertyName": "Licenses",
                    "status": "Successful",
                    "value": "Contact Center, Interact, Attendant Console, Assistant, External Task, Audio/Video"
                }
            ]
        }
    ]
}

Troubleshooting

In any regular scenario, bulk-updating users should run and show as successful. If the operation fails for any reason (e.g. an operation timeout or contradicting operations by other admins), the Bulk Operation will show as partially successful when some data entities were updated or failed when no entities were updated at all.

In case of a Partially successful or Failed result you can inspect which users were not updated.

If your Bulk Operation fails repeatedly:

  • Retry the bulk operation with the failed users.
  • Check if single-editing those users is possible.

If workarounds are not effective even after repeated attempts, please download the JSON, take a screenshot of the operations window -  preferably with a visible timestamp of your failed operation - and get in touch with Luware for technical analysis.

INC Luware Support Address

 Luware Website https://luware.com/support/
Luware Helpdesk https://helpdesk.luware.cloud 
Cloud Service Status https://status.luware.cloud/
Luware support contact details
 
Best Practices - Bulk Editing

Bulk Editing allows users to make simultaneous (configuration/setting) changes to...

License Management

On this page the following topics are covered: How to get access to licensing opt...

Table of Contents