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. 

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.

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.

 

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 and Bulk Operation outcomes

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

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

💡Visible effects

• As you add or remove users during Bulk Editing, the view changes depending on their (mis)matching feature set. A yellow license mismatch will always be deselected first, then you can select the property again, turning it “green” for all users.
• Feature tabs become visible depending on the users' individual licensing. On a mismatch between users, a tooltip will inform why tabs are greyed out, e.g. because licenses are missing for one user.
• As you make any changes on properties (e.g. assigning a license to all users), the color code changes and the "Save" button becomes enabled. Sometimes, saving these changes is required (e.g. save and apply licenses first before enabling a tab for all users).

💡Background effects 

• Removing licenses from users behaves the same as described in License Downgrade. A removed license takes immediate effect (see note below) and can be assigned to another user. 
• 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.

☝Note: the configuration reset from a license change is irreversible. Removing a license - either single or in bulk - also removes any previously configured Nimbus Features and related UI tabs and functionality for that user as soon as you save your license changes.

→ Make sure that you Bulk Edit the correct users as you make comprehensive license changes.

 

 

 

👁Inspecting Bulk Operations

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.

⮑A click opens the “Bulk Operation” window that reveals which users have been modified and which values were changed 

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

{
    "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 not cause any issues. If the operation fails for any reason (e.g. an operation timeout, simultaneous operation by other users), the Bulk Operation will show as partially successful or failed.

Workaround: 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/

 

 

 

 

💡These tabs are not available during Bulk Editing. Please refer to chapter “Before you start” and the “Known Limitations” for more details.

✅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.

✅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. 

✅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. 

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

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. 

✅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.