Organization Units

An Organization Unit (OU) is like a 'container' that represents the hierarchical, logical structures within your organization. A LUCS user can assign agents, services, workflow resources and other related configuration elements to any OU. This allows a distributed use of accounts, data entities (resources, settings, configuration sets) based on that organizational model. Organization Units can also be nested, allowing for child elements inheriting parts from the parent.

For example: a "Technical Support" OU Root can be further split into "Support Switzerland" and "Support Germany", but they all inherit configuration elements and resources you specifically assign to the "Technical Support" parent.

As LUCS administrator it is up to you how to structure the Organization Units. A good approach is to define the OU according to the divisions in your company, so each one can have its distinct set, but still be categorized under a parent.

By default a '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 LUCS to signal that any OU below will inherit the features.

The 'Organization Units' page is accessible on Settings -> Organization Units:

WebConfigurator - 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.

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:

Control Name	Description
Name	The name of your Organization Unit. This will appear throughout other parts of the LUCS Configuration, so make sure to pick a clear name that avoids confusion.
"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. When deselected only entities of the currently configured organization unit, its parent one and assigned the "System" organization unit are available for configuration. When selected additionally dependent entities of its child organization units will be available for selection during 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 You can move "Not Ready Reasons" to be made available to your organization unit using the 'left' and 'right' arrows.
TTS Language Definition
Language	The Text To Speech Languages are used by the system for announcements/statements defined on the "Announcement" Workflow Activities → See Workflow Activities. If for an Organization Unit and Culture defined on a service a matching TTS Language is found, the defined voice should be used. If no TTS Language is found than based on the selected culture the system tries to find the first matching installed TTS . The 'Add TTS Language' field shows the languages chosen for this Organization Unit. The TTS Language are culture dependent entities and are shown in the format: Language (Country) TTS Voice
Add	Add a language for the Organization Unit by selecting the 'Language' and 'TTS' and clicking the '+ Add' button. Precondition: to be available in the dropdown, the TTS languge should be installed on the LUCS server where ICH server is made available.

Organization Unit changes on existing (in-use) data objects

Good to know

Once an Organization Unit is applied to any type of data object it may be used for reference and accessed by LUCS users and services as originally defined under the Role Based Access - RBAC permissions Matrix.

When the Organization Unit for this source data object is changed for any reason, existing Services / Agents / Users may still continue to use that data entity for long as their settings-assignment to this entity remains unchanged.
Once the data entity is deselected, RBAC permissions are automatically checked against and updated. This may result in the same entity not being selectable anymore if new the Organization Unit / Role Based Access - RBAC matrix forbids to do so.
The same concept consistently applies to all data object in LUCS, such as:
- Common Service Settings when used in during Call and Mail Services configuration.
- Workflow Resources and Dependencies used in various workflows.
- Agent Management related data objects such as Duty Profiles and the Trait and Responsibility Definitions.

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 automatically shifted to the parent root node.
On a child note this happens in the background and without further notice once you press "Delete".

Deleting a root node with underlying dependencies will result in a warning, that the dependent items will shift to the next parent node. The last parent node is "System" level.

Changing Organization Units (on existing data entities)

As almost every data entity (workflows, services, users, etc.) in LUCS 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 LUCS team. An example of this would be a Service relying on a Workflow that is now being made available to more service teams.

Example

Scenario

In this case lets assume:

Workflows = Blue
Service = Orange

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

Outcome:

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

Outcome:

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.
→ Read more in the chapter below.

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.