An Organization Unit (OU) is like a "container" that represents the hierarchical, logical structures within your organization. This concept is also used to distinguish Role Based Access - RBAC by different departments or functional roles in your company. A Stratus Agent admin or supervisor can assign agents, services, workflow resources and other related configuration elements and data enttities to any OU. This allows to manage distributed accounts and restrict access to resources based on that organizational model.
Furthermore, Organization Units can also be nested. This creates a relationship where child elements inherit parts from the parent. For example: a "Technical Support" OU Root node can be further split into "Support Switzerland" and "Support Germany", but they all inherit configuration elements and resources you specifically assign to "Technical Support" or any other higher level OU.
By default a highest level "System" organization unit is created as parent for all other ones. This unit cannot be deleted and is not displayed in the list on "Organization Unit" page. It may however appear in several configuration parts of Stratus Agent to signal that any OU below will inherit the features.
The "Organization Units" page is accessible via Webconfigurator > Settings -> Organization Units:
Add Organization Unit
To add a hierarchy of the organization units click "+ Add Root" or "+ Add Child" buttons. From here on you have several options:
- Make changes to the OU as needed (see chapter and table below)
- To save the changes, click "Save&Apply" button.
- To save changes and continue adding of one more organization unit, click "Save&New" button. The new organization unit is added to the list immediately.
- To roll back the changes, click "Reject" button.
Edit Organization Unit Details
Click on a a specific Organization Unit in the list, the user can view its details:
The Organization Unit panel contains the following settings:
The name of your Organization Unit.
"Allow to assign and use dependent entities of child organization units"
Defines if dependent entities of child organization units will be visible on Agent or Service details and their settings configuration.
Not Ready Reasons
Not Ready Reasons
Use this in conjunction with the Agent Assistant application. This asks the agent for a "Not Ready Reasons" every time his state changes to a "not selectable" one.
Precondition: Not Ready Reasons should be configured on Settings -> Agents -> Reason Types page
TTS Language Definition
The Text To Speech Languages are used by the system for announcements/statements defined on the workflow activities.
Precondition: to be available in the dropdown, the TTS languge should be installed on the Stratus Agent server where ICH server is made available. Also see Architecture
Add a language for the Organization Unit by selecting the "Language" and "TTS" and clicking the "+ Add" button.
Delete Organization Unit
To delete an existing organization unit, simply click "Delete" button.
Any agent, service or workflow resource is currently using the organization unit will be shifted to the higher root node. On a child note this happens without further notice after you press "Delete".
Changing Organization Units (on existing data entities)
As almost every data entity (workflows, services, users, etc.) in Stratus Agent is specifically assigned to one Organization Unit it can be very likely that this OU-assignment is changed by an Administrator at a later point of time and maybe even during productive use. The intent could be to make that entity (e.g. a Workflow) accessible to a new Stratus Agent team. An example of this would be a Service relying on a Workflow that is now being made available to more service teams.
In this case lets assume:
Note that this example generally applies for any other data entity, including Users / Agents / Resources
Scenario A: Moving entities up along the path
A Workflow in this example shifts from "Support" higher along the path to "Tenant" level
This will not cause a problem as all Tenant-underlying OU continue to have access to the entity.
"Luware UK" and all future added OUs will inherit everything from "Tenant" level.
Scenario B: Moving entities to a different branch
A Workflow in this example shifts from "Support" to "Luware UK" OU
Luware UK now has access to the workflow entity.
However the Service in the "Support" OU doesn't "see" the workflow anymore, because its in a different path.
The "Support" OU-situated Service will now have a "Non-Path-Dependency" but still relies on access to the workflow.
Non-Path-Dependency and UI Warnings
To ensure that operation and reliance on existing dependent entities can still continue - e.g. a Service depending on a workflow or resource that moved to a different OU - the data entity remains accessible on entities even with their Organization Unit shifted. However, other users can understandably be confused why certain entities are not selectable via dropdowns anymore - for example because an Administrator has changed the OU placement without their knowledge.
For that reason the UI will now display a "Non-Dependency Warning".
NPD - Non Path Dependency Warning behavior:
- On mouseover the following warning will be shown: "This is a non-path-dependency and it's only shown because it is currently assigned"
- The warning itself has no systemic effect on existing service operation and is just there to inform the user about the shifted OU-assignment of this entity.
- Once the selection (by any user with access to this entity) is made away from an NPD-flagged entry, this entry is not selectable anymore.