Best Practices - Bulk Editing

Bulk Editing allows users to make simultaneous (configuration/setting) changes to multiple entities within Nimbus. This capability is particularly beneficial for both large and small companies that frequently need to adjust common configurations or assignments.

➕Benefits

Compared to single-editing entities (e.g. user and service details), Bulk Editing offers clear benefits: 

  • Significantly enhance efficiency, speed, and accuracy of large-scale adjustments.
  • Implementing settings standardization and consistency across Organization Units, roles, and functions.
  • Keeping a clean review record, e.g. by reviewing detail changes (usually) with fewer acting administrators involved.
Details after a Bulk Editing operation can be inspected, including a JSON file as a track history record.

➖Risks

Bulk Editing is powerful but also allows to potentially misconfigure your Nimbus instance and related users. The primary risks involve

  • Removing (previously) configured features by removing licenses in bulk.
  • Applying unwanted (custom) features for a userbase that actually relied on individual solutions.
  • Interrupting existing service operations, e.g. by assigning Responsibility Profiles to users that hold no value for distribution.
  • Adding Nimbus Features  (e.g. new Modalities or Addons) in large-scale, potentially confusing Nimbus Portal users.

💡We also summarized some specific details in the → Considerations chapter below.

Related to the feature, please consider the following currently known limitations which are either by design or tracked as a known issue. We will continuously update this item as we develop Nimbus, so check back regularly with each update, also on our Latest Release Notes.  

 

INC Bulk Editing Limitations

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.

 

Considerations

Licensing

On a license-enabled feature mismatch, Nimbus will always default back to the “General” Tab as common ground so you can adjust a (missing) license. Editing License options  (e.g. like in General User Settings)  may not be if entities differ in certain criteria such as used functionality or the way the service/user was provisioned.

💡As there are license and setting co-dependencies between tabs, also note that any pending changes must be confirmed one tab at a time.

Insufficient Licensing warning

License downgrades result in loss of configuration

☝Removing Licenses (in bulk) will also remove all previously configured Nimbus Features related to that license.  → Restoring a (previously removed) license in bulk will only establish the default settings.

 

Recommendations

  • Perform License changes (either add and remove) in smaller batches or on single edit first to learn about the effects on the UI. 
  • Consult our pages on License Downgrade and Nimbus Features respectively prior to changes to learn about the change impacts.
  • Note that License Management restricts how many licenses can be assigned in bulk, so ensure you have enough as you may not be able to bulk-assign over the given limit.
 
 
 

Users: Skills and Profiles

While Bulk Editing Skills and Responsibilities in the Skills User Settings tab, also consider which Responsibility Profiles should be assigned alongside.

Keep in mind that the UI will show all profiles and skills of the Users you are bulk editing. Adding additional elements may immediately reflect in the users' Assistant (UI and App) selection.

Skills and Profiles show an entry selection from all Users. Adding profiles will reflect back on the User UI.

The Team owners also need to be made aware of changes on skills and profiles as they can (should) adjust each new profile and the related skill levels in their Agent Service Settings

Each new profile results in a necessary adjustment for User skills (and responsibilities) .

Recommendations

 
 
 

Users: N/A Reasons

While Bulk Editing Not Available Reasons (NAR) keep in mind that the order and amount of items is reflected in the Assistant App and Nimbus UI of all affected Users. 
 

Be aware if the order of items really “Applies to All” your Users.

As Users get Nimbus tasks while being Not Available, the topmost NAR entry is presented their default. Keep this in mind as Users might habit-click into their their “usual” response. 

The selected reason also reflects in historic reporting OData Feed as part of the Nimbus Reporting Model, so changing the reasons completely might be something that your BI specialist might be interested in known.

Recommendations

  • Efficiency matters - Talk to Users what their most-chosen reasons are and sort the list accordingly.
  • “One size fits all" for ordering your reasons in bulk might not always be the best approach, as Users might have individual preferences on their default.
 
 
 

Users: Interact

While Bulk Editing Interact User Settings consider that the configured Modalities run aside from General User Settings. This means that Interact can bypass services, allowing customers to directly contact a User via website widget.

Interact settings do NOT affect your services, but may open your Users up for external customer interaction outside of a service queue.

In the same way, access restrictions for Interact Domain Templates (CORS) affect your Users only, not their services, which have own Interact Service Settings.

Recommendations

  • Opening modalities up may instantly allow customers to contact your Users via existing website widgets. Ensure that both your Users and your webmaster are aware of the new contact methods.
  • When restricting access to multiple Users, consider adjustments to your Interact Domain Templates (CORS), as you could edit Users that might offer Interact services from a different website (e.g. different “follow the sun” partners or different country domain endings)
 
 
 

Users: Assistant

When Bulk Editing Direct Call Templates for Assistant, take special note of their order of execution as well as the Organization Units they are placed in. 

Templates may not be meant for every user, but specifically catered to a certain service or external system that not every of your users have access to. 

A template with a NPR (Non-Path Reference) warning may indicate that either the User should not (normally) access it.

In the same fashion, a Non-Path reference warning (yellow) indicate that a template (or your users) were moved to a different Organization Unit, so it's highly recommended to double-check if the template itself still applies.

Recommendations

  • Order or execution in Direct Call Templates matter. Ensure that they do not create dependencies on each other that fail when executed in the wrong order (e.g. “create a CRM ticket on call then update it).
  • Checking either Organization Units placement of your templates with NPR warnings may be required to see if the template is either placed in the wrong spot or not meant for that user's Organization Unit to begin with.
 
 
 

Table of Contents