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.
- Enforcing settings standardization and consistency across Organization Units, Portal Roles, KPIs and other related service settings.
- Easier License Management when enabling or disabling Nimbus Features in bulk.
- Keeping a clean review record, e.g., by reviewing detail changes (usually) with fewer acting administrators involved.
➖Risks
Bulk Editing is powerful but also allows potential misconfiguration of your Nimbus instance and related Users. The primary risks involve:
- Removing (already configured) features. Deactivating certain features may also remove related settings, re-applying will set defaults.
- Applying unwanted (custom) features for a Userbase that actually relied on individual solutions.
- Interrupting Service operations, e.g.by assigning workflows, changing KPIs or distribution settings that affect productive Services.
- 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
☝Bulk Editing is in active development. We are continuously updating this feature over the coming months.
☝Please read the following 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 Cannot be changed in Bulk (yet) as these settings rely on many dependencies configured on additional tabs.
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 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.)
-
Users with only Custom Roles assigned don't have the Bulk Edit feature available. → An “Organization Unit Admin Role" needs to be granted to Bulk Edit entities within the corresponding OU.
⮑ The OU entities that the Custom Role has access to cannot bulk edited due to a lack of permissions.
- “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 Bulk Editing it is 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 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.
💡 Note that the Non-path Reference warning (caused when changing Organization Units) is currently not shown in the Roles tab. This is a known limitation and subject for future improvement.
🔎 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 any known limitations.
Considerations
General
Licensing
Licensing
General default: 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.
License mismatch warnings may prevent selection for Bulk Editing. Tooltips will inform about the dependencies:
License count warnings may be shown when there are not enough available licenses for bulk assignment:
Changes must be confirmed one tab at a time, as (licensing or bulk-related) changes can create co-dependencies between tabs.
☝Note: License downgrades will remove existing settings
Removing Licenses (in bulk) will also remove all previously configured Nimbus Features related to that license.
→ Ensure you are certain to remove features from Users or Services in Bulk, as the action cannot be undone.
→ Restoring a (previously removed) license in bulk will only establish the default settings.
Recommendations
- Initially, we recommend to perform license changes in smaller batches – or in single edit first — to learn about the effects on the UI.
- Consult our pages on License Downgrade and Nimbus Features respectively to learn about license change impacts.
- Before applying licenses in bulk, review your License Management, as assigning extra licenses over the available limit is not allowed.
Services
Services: Feature and Configuration Dependencies
Services: Feature and Configuration Dependencies
When Bulk Editing Services, pay special attention to certain technical and configuration prerequisites.
Before selecting multiple Services: Note that Services need to be of a matching User Assignment Type (MS Teams-based OR Skill-based) and Service Types (comparable feature set with according licensing constraints).
💡This depends on how the the Services were originally provisioned, e.g. manually in Nimbus Admin Portal or directly via MS-Teams.
→ Whenever selection boxes are greyed out, check the tooltips for more information.
While configuring multiple Services in bulk, note that Services can share a lot of related Configuration entity dependencies (e.g. Opening Hours, Workflows, Distribution Policies). Each configuration entity itself can have further (nested) dependencies, such as:
- Playlists with Resources (audio files) sitting in various Organization Units, because they were originally intended for a certain language or region.
- Distribution Policies that refer to Skills and Responsibilities as their requirement. These related Skill and Responsibility levels are also configured on existing User's Settings.
- All entities each have an Organization Unit (OU) definition. By applying them to Services in different OUs you create non-path references (NPRs) that act as an “exception from the rule”. Other Service owners can see and use this new configuration, but may not select it again once deselected, as the OU visibility rules will be enforced again.
Recommendations
☝Before using Bulk Editing settings on already productive Services, please note the following:
- Consult the Bulk Editing Services page for individual Prerequirements and other dependencies.
- Nimbus will accept any changes Make sure to check that the data entities you bulk-change towards (e.g. workflows, distribution policies) actually “fit” all the Services.
💡For example, a workflow could contain announcements in a certain language or check Parameters from a CRM via Power Automate Flows which provide data only suitable for Service A, but not Service B. - Instead of point-blank overwriting settings, consider moving, copying or creating new Configuration entities to switch towards, e.g. by moving them to a “higher” Organization Unit (OU) level and using resources that are equally accessible by all Services. This also ensures that you could fall back to the “deeper” OU items if certain Services run into problems.
- When unifying settings that greatly impact the Service performance (e.g. KPIs, Opening Hours, User Skills, Distribution Policies), make sure to inform the individual Service Owners ahead of time, as it is guaranteed that follow-up actions will be necessary to cover the adjustments. Such follow-ups could be:
- Instructing Team Managers to checking Agent Service Settings, by matching Skills and Responsibilities to a new (unified) distribution policy.
- Notifying your Nimbus Reporting specialists that KPIs have changed, so they expect the changes in their data evaluation.
- Inform technical Service Admins about changes that could influence their running Power Automate Use Cases and other dependencies for such automations, e.g. Opening Hours, Parameters, Workflows.
Users
Users: Skills and Profiles
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.
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.
Users: N/A Reasons
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.
As Users get Nimbus tasks while being Not Available, the topmost NAR entry is presented as 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 to know.
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
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.
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
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.
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 doublecheck 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.