Delegated Administration and Organizations

In this section:

Overview

This page describes delegated administration and discusses relevant concepts. Review this page carefully before deciding if you should implement delegated administration. See Implement Delegated Administration for detailed implementation procedures.

You can create a two-level hierarchy that allows you to create individual organizations such as a school within your university. You can then delegate some aspects of EchoSystem administration to the school. With delegated administration, an individual school can create users, schedule rooms, and manage sections. It can also define its own policies on such subjects as frequency of capture, the need for confidence monitoring, retention policies, and many other topics. However, an individual school may not have the resources to perform system administration operations, such as configuring the streaming server, configuring the web server, or configuring the file transfer server. These can be handled by a university-level IT department that supports each individual school.

Delegated Administration is Optional

You do not have to delegate administration. Delegating allows individual schools or departments to customize the EchoSystem for their needs. If this customization is not of interest, do not create individual organizations. All objects will be owned and managed by the parent organization.

About Hierarchies

A typical hierarchy mirrors the organizations in your institution that use EchoSystem, as demonstrated in the diagram below:

diagram of hierarchical organizations as described.

This example hierarchy consists of one parent organization (your university) and three child organizations (the law school, the medical school, and the business school). You can have only one parent organization but any number of child organizations.

The parent organization need not be the university. If you want a more granular organization, you could have a hierarchy like that shown in the following diagram, where the parent organization is the Engineering school, with three child organizations representing the different disciplines (electrical, mechanical and civil):
diagram of school hierarchy as described.

You can create only one, two-level hierarchy per EchoSystem Server (ESS). You cannot create both of the hierarchies illustrated above in a single ESS.

To add the organizations that create hierarchy, see Manage Organizations.

When you create a hierarchy, three other concepts become important:

Organizational ownership
Inheritance
User roles and rights

Organizational Ownership

Objects are entities within the EchoSystem. With the addition of hierarchy, it is possible for organizations to own objects. Owning an object means having the ability to schedule it, use it, or share it with another organization. Both the parent organization and the child organizations can own objects and, in a typical configuration, both do. However, certain objects can only be owned by the parent organization.

Some objects can have shared ownership:

When an object is shared, organizations other than the owner can schedule or use the object.
Only the owner can modify the properties of the shared object.
Objects owned by the parent organization are automatically shared with all child organizations.
Child organizations can own objects but cannot share them. Only the parent organization can share objects.

Rooms and courses are commonly shared:

Rooms. You might share a room when two different child organizations (say, the Engineering School and the School of Arts and Sciences) use a room and want to be able to schedule courses for it. It is good practice for the parent organization to own the room and share it.
Terms. If the term is the same among organizations it is good practice for the parent organization to own the term and share it.

Courses, by contrast, are commonly owned by a single organization, so that school only can customize the course and other schools cannot manage it.

The table below gives ownership details for all objects.

Object	Can be owned (and shared) by parent organization?	Can be owned by child organization?	Can be batch moved to another Organization?	Comments
room	Yes	Yes	No	Rooms and capture devices depend on each other to function. A room and the device assigned to a room must be owned by the same organization. The move operation will check some dependencies before completing.
term	Yes	Yes	No	A term can be owned by a child organization but cannot be moved to another child organization.
device	Yes	Yes	Yes	Rooms and capture devices depend on each other to function. A room and the device assigned to a room must be owned by the same organization. Devices can be assigned to any organization at registration time. The move operation will check some dependencies before completing. You can move many devices at once by exporting then importing rooms.
content security module	Yes	Yes	No	A content security module can be owned by a child organization but cannot be moved to another child organization.
media processor	Yes	Yes	No	Initially, all media processors are owned by the parent organization. Media processors owned by the parent organization share the load for all child organizations. A media processor owned by the child organization handles jobs only for that child organization. A child organization Administrator can change job priorities only for media processors owned by the child organization.
publisher	Yes	Yes	No	A publisher can be owned by a child organization but cannot be moved to another child organization.
course	Yes	Yes	Yes	Courses own sections. If you move a course from one organization to another, all related sections move with the course. When a section moves, certain other objects move with it. See the description of section in this table for details.
branding asset	Yes	Yes	No	A branding asset can be owned by a child organization but cannot be moved to another child organization.
section	Yes	Yes	Yes	Sections own certain other objects: schedules, capture records, and Echoes. When a section moved to a new organization, all of these objects move with it. A capture record is the unique record for the specific capture. It appears in the Monitor tab when the capture is running and in the logs after the capture completes. You can move many sections to a new organization at once by exporting or importing sections.
schedule	Yes	Yes	Yes	Schedules are owned by a section and move with the section. If you move a section from one organization to another (from child to child, from parent to child, from child to parent), the schedule for the section moves with the section.
Echo	Yes	Yes	Yes	Echoes are owned by a section. If you move the section to a different organization, Echoes move with the section. Content Security May Change If the new organization has a different security module, users may not be able to access Echoes after a move. After moving Echoes to a new organization, check the security module to ensure that the required credentials have not changed.
campus	Yes	No	No	A campus cannot be owned by a child organization but the child organization Administrator can add or edit a campus when adding a room.
building	Yes	No	No	A building cannot be owned by a child organization but the child organization Administrator can add or edit a building when adding a room.
application security module	Yes	No	No	The application security module supports querying multiple LDAP servers and trees. See LDAP Authentication.
license	Yes	No	No	All licenses are owned by the parent organization. Both parent and child organization Administrators can assign licenses to venues and users. We recommend that Administrators coordinate their efforts to ensure proper license assignment.
trusted system	Yes	No	No	--
user	Yes	No	Yes	All user objects are owned by the parent organization and assigned access rights to both parent and child organizations through roles. You can assign many roles at once by exporting or importing users.

User Roles and Rights

When you create a hierarchy with a parent organization and child organizations, certain roles are associated with an organization. Others are associated with a section. This distinction is important because organization roles are defined on the User page in the ESS (Configuration > Users) but section roles are defined on the Section page (Schedules > Courses).

Rights "flow down". This means that the Admin at the parent organization level can make configuration choices for any child organization. Say, for example, that the Admin at the parent organization has specified that the Days to Keep Originals setting is 120 days. However, the business school is running short on storage space and the Admin for the business school is on vacation. The parent organization Admin can change this setting for the business school. The business school is lower in the hierarchy, so the parent organization Admin has access rights.

For details on the different roles and instructions on adding users, see Manage Users.

Licensing

A license is an object and, like all objects, a license owned by the parent organization is automatically shared with child organizations. This means that any existing course, venue, or user can be assigned a license because it can use the parent organization license.

On upgrade, all licenses are owned by the parent organization.

A license can be purchased by a child organization and used only for that child organization, but the license will always be owned by the parent organization. Parent organization licenses are still shared and can still be used by a child organization that has purchased its own license.

See Manage Licenses for details.