Bulk Editing is a feature that allows users to make simultaneous changes to multiple entities (configuration) within Nimbus. This capability is particularly beneficial for both large and small companies that frequently need to adjust common configurations or assignments.
Benefits
Bulk editing significantly enhance the efficiency and accuracy of large-scale adjustments. As you update multiple entities at once, setting standardization and speed are primary benefits. By monitoring detail changes during bulk editing with (usually) with fewer acting Administrators involved, keeping a clean history can increase the value and reliability of this feature.
Risks
Bulk Editing is powerful, but also allows to potentially misconfigure your Nimbus instance and related users. We therefore summarized thoughts in our → Considerations chapter below. The primary risks include:
- 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.
Please also take in consideration the following currently known limitations, 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 limitations 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 Edit - Users Only: This feature is currently intended to allow only user bulk editing. Further configuration entities (e.g. services, configuration items) will follow at a later date.
What can be changed in Bulk | What can't be changed in Bulk |
---|---|
|
|
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. We are actively planning new approaches in future updates.
🤔 What design limitations are there?
💡By current design: (below were 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 users can be edited at same time.
- If the number of entries in the user list is larger than 25, “Select All” is disabled.
- You have to filter your users to below this threshold to apply changes.
- No bulk creating/deleting users - While in bulk edit mode, users cannot be mass created or deleted (as a precaution.)
- Dependent changes - Certain features rely on dependencies (e.g. a change-enabling additional feature tabs). For this reason, there are editing differences, requiring you to confirm partial changes first before applying further bulk changes.
-
Limited Changeset view - The “Details” inspection feature next to the “Save” button only shows complete set of changes, no delta changes (this is a technical limitation at the moment). Any changes will always be a full value list. Please be patient as we are working on a dedicated change history feature.
💡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.
- Search deletes user choice - The user search currently deletes any existing bulk selection. You have to manually select users from the paginated list to continue bulk editing.
🤔 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.
🤔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 this user as “Agent” ) will still consider the user for tasks as long as the user itself is not actively removed from their 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
While Bulk Editing Licenses in the General User Settings, be aware that not all sections and options will be available if users differ in their licenses. On a license conflict, Nimbus will always default back to the “General” Tab as common ground so you can adjust a (missing) license.
Also note - as there are license and setting co-dependencies between tabs - , changes can only be confirmed one tab at a time.
Loss of (prior) Feature configuration
Just to mention it again for safety: Removing Licenses (in bulk) will also remove all previously configured Nimbus Features related to that license. → Pay close attention when removing Licenses from users which already had a prior configuration, as saving the license has immediate effect.
Recommendations
- Perform License changes (either add and remove) in smaller batches first to check their effects on the UI.
- Removing Licenses in Bulk is easily done, but also removes settings of users just as quickly. Consult License Downgrade and Nimbus Features respectively prior to changes.
- 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.
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.
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.
Recommendations
- After a change to skills and profiles you might want to adjust Distribution Policies to include those new elements.
- Inform both Service / Team Owners and affected Users of a pending change to their Profiles, Agent Service Settings and related Distribution Service Settings where (potentially changed or new) policies might apply.
- After making large changes to your skill-based distribution, it might be a good idea to go through Use Case - Setting Up a Contact Center again as a checklist.
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.
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.
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.
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)
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.
In the same fashion, a Non-Path reference warning (yellow) indicate that a template (or your users) were moved to a different Organization Units, so it's highly recommended to double-checking if the template itself still applies.
Recommendations
- Order or execution in Direct Call Templates matters. 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.