Nimbus uses Organization Units (OU) to structure and manage all its configurable data entities. Everything in Nimbus follows this concept, including services and users. This allows for a very granular concept of both visibility, access, and permission.
OU Access Concept
To understand Organization Units, it is important to know their relationship with Roles and Permissions:
- Each configurable element in Nimbus is called an entity (of configurable data).
- Organization Units provide a structure to Nimbus's entities, e.g. by mirroring a company's organization levels and departments.
Learning 1: Everything has an OU place
💡 Organization Units determine where a configurable entity is placed.
💡 Each entity must belong to exactly one Organization Unit. This includes all Nimbus users, as their OUs determines from which "point of view" they can act in their role.
Nimbus Role-based Access Concept (RBAC) grants access within any Organization Unit, e.g. by assigning functions to users according to their role in the organization.
Learning 2: OU and RBAC tie in together
💡 RBAC determines which actions (Create, Read, Update, Delete) are possible on configurable entities.
💡 User roles define sets of action permissions granted within an OU.
Reading along the path
As a default permission the combination of RBAC and OU allows all authenticated Nimbus users to "read" all configurable entities up the path. To visualize this concept it helps imagining your OU structure like a tree with branches, using following rules:
Learning 3: OU determines visibility
- The highest level of your OU tree is always the "Tenant" level. No configuration element can be placed higher than that.
- The sub-OU nodes are connected as "branches" to your organization tree. Examples would be your different service teams or departments. Each team can configure their own set of workflows, error codes, etc.
- Entities can be read "up to the root" to Tenant level. This means each Service Team and its members in the example above can "see" data from all higher-level OU, e.g. provided by a manager or administrator.
- Entities cannot be "seen" between the same OU level. This means that each Service Team and its members cannot access data another team on same level, nor can they look into any other OU-branch and its data.
GOOD TO KNOW
💡 Any Tenant Administrator can access all data entities to change their Organization Unit assignment, e.g. to move a configuration item "up" tenant-wide or assign it "down" to specific team.
💡 There is no limit to OU levels and configuration items, but we recommend to keep your OU structures simple at first and expand later. This keeps both visibility and RBAC access management transparent in case you need to error-resolve and test.
🔍 Important Note: Adding further OU branches to your tree is easier than removing them, as each OU assignment creates path dependencies. Read more on this below.
OU (non-) path references
Even after using an entity somewhere else - e.g. a Template being referenced within a Settings dialogue - a later change in the OU is possible. Changing the OU in such a reference causes a non-path-reference (NPR) warning.
This has the following effects:
⮑ Affected services will continue to function normally but display this as a "Non Path Reference" warning on the affected entity.
⮑ Once unassigned / removed from a configuration dialog, the entity will not be visible within that OU anymore, as the "reading along the path" rule is re-applied.
Learn more about Non-Path References…
INC Non-Path Reference
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.
Managing Organization Units
PRECONDITIONS
Access to the Nimbus Admin Portal is needed to be able to create and manage organization units. Contact your tenant administrator or customer service support for access.
Creating a new Organization Unit
- As Administrator login to the admin portal and access the “Configuration”
- Locate "Organization Units" in the Configuration list.
- Click on "Create New" → a dialog window will open.
- Specify the name, parent and if needed a description can be added too which will be shown.
🔍 Please note:
- OU structures can be nested in parent-child relations. Users and Services within an OU are counted in the listing.
- These structures can then be used to assign any entity to a specific parent or child OU.
Grant users access to specific Organization Units
✅ After setting up your OU structures you might want to delegate specific administrative tasks to other users. Here is how to do this:
- Login as a Nimbus Tenant Admin and go to "Users" (→ 🔍 also see User Administration)
- Select the user(s) you want to give access to a specific Organization Unit and go to their "Roles" tab.
- Click on "Add" and select the role of "Organization Unit Admin" → a warning sign will appear since no OU is yet assigned.
4. Click on the "Edit" button to assign at least one Organization Unit.
5. The user whom the Organization Unit has been assigned to can now login to the admin portal and access only that organization unit.
Apply Organization Units to existing configurations
✅ As (OU) administrator you can also re-apply a new Organization Unit to existing Configuration data entities (e.g. workflows, playlists, resources).
- Open the admin portal and log in as either OU admin or tenant administrator.
- Go to any configuration item, e.g. workflows.
- Change the Organization Unit of the entity. ☝ Limitations apply, see below.
EXAMPLES OF USE
While it's up to you to structure your Organization Units and configuration data entities as you like, here are some examples to sort by:
- By your organization: e.g. tenant-wide Opening Hours calendars with all company-wide special hours or holidays defined, inherited down and useable for all services in your tenant.
- By regional differences: e.g. a set of audio file resources to be used in common. This can be combined with a sub-OU handling region-specific playlists and files - e.g. a company callsign, slogan or jingle, followed by a local "German" greeting for each customer.
- By department: e.g. by adding a set of task completion codes that are only used within the Sales team OU, service team OU, support team OU, etc.
☝ When managing OU with multiple admins, ensure to agree on a common denominator. You can change OU structures and assignments later, but this will create non-path dependencies and may cause confusion for your service administrators as data visibility and permissions can suddenly change without prior notice. → Also refer to the "Known limitations" below.
RELATED PAGES
- Role-based Access Concept - granted in tandem with OU assignments to grant access to entities and features.
- Configuration - where individual data entities are created and assigned to individual OU.
- Service Settings - where previously configured entities are applied (reading along the path applies).