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
OU STRUCTURES AND RBAC PERMISSIONS
To understand Organization Units, it is important to know their relationship with Roles and Permissions:
- Each configurable element in Nimbus is called a data entity.
- Organization Units provide a structure to Nimbus's data entities, e.g. by mirroring a company's organization levels and departments.
💡 Organization Units determine where a configurable data entity is placed.
💡 Each data 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.
- RBAC - Role Based Access Control restricts and grants access within any Organization Unit, e.g. by assigning functions to users according to their role in the organization.
💡 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:
- The highest level of your 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
💡 A tenant administrator can access all data entities and 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 dependencies
A later change in any configuration entity's OU assignment is possible, but may cause a non-path-dependency (NPD) warning, e.g. when a sound file used in a playlist shifts to another OU. This has the following effects visible to your Nimbus users:
→ Affected services will continue to function normally but display this as a "Non Path Dependency" warning ☝ on the affected data entity.
→ Once unassigned / removed the entity will not be visible within that OU anymore, as dictated by the the "reading along the path" rule.
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 data 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).