The Echo360 active learning platform allows for a three-tiered organizational hierarchy using the following levels: Institution > Organization > Department. The Institution (also referred to as a "tenant") is the top-most level of the hierarchy and represents your Echo360 institutional account.

Within each institution, there can be one or more organizations. Typically the organization identifies a school within the university, such as a Medical school or Business school or other entity. Each organization can then have one or more departments, such as the Nursing department or the Accounting department.

When you create courses, you can assign those to an organization and/or a department. Org/Depts are not required, but they can be useful for finding and categorizing courses and the sections that reside within them. In addition, system features, such as content downloads or Q&A tab access, can be enabled or disabled at the institution, organization, and department levels.

Delegated Administration is just that; the ability to delegate admin users to different hierarchical levels (orgs and depts) in your institution. As such, it relies on the use of organizations and/or departments within your institution

Delegated administration effectively allows or restricts access to courses/sections and features based on their association with a level in the hierarchy. Meaning that an Admin who is given rights to only Department X and Y can enable or disable features for those departments, and create, edit, or delete courses, sections, and section schedules for only those courses associated with those departments.

At the time Delegated Administration (DA) is enabled, all existing admins in the system are automatically given institution-level administrative rights. All Admins created AFTER DA is enabled have NO rights to any level of the hierarchy and must be explicitly provided with administrative access.

Delegating admin access to a particular organization or department limits that admin's access to the following:

• Courses within that organization or department and their associated sections.
  For example: you can only create a course within the organization or department to which you have administrative rights. You can edit any course within your org/dept of access but you cannot move the course to an org or dept to which you do not have rights.
• Section scheduling for sections associated with courses within that organization or department.
• Captures that have been published to a section within the organization or department.
• Captures that are scheduled for sections within the organization or department and will be auto-published there.
• Section Feature toggles (on the Institution Settings page) for that organization or department.
• The ability to create organizations or departments if the access-level does not allow it.
  For example: organizations can only be created by an admin with institution-level access; departments can only be created by an admin with organization-level access.

  IMPORTANT: If you have courses in the system that are not assigned to an organization or department, only administrators with Institution-level permissions will have access to those courses and their sections. You may need to assign or re-assign items within your system accordingly.

If delegated administration is turned on for the institution, you will see an Administrators tab on the right side of the Institution Settings page. Clicking on an organization or department level to which you have admin privileges changes the right panel to show the options you have.

Click Administrators to edit which administrators have rights to that level. You will NOT see your own name; you cannot add or remove rights for yourself. Another admin must do that for you. 

The figure above shows what an organization-level admin will see, and how to view the list of Administrators for that level. If an organization or department is grayed out, you do not have administrative rights to that hierarchical level. If you click on a grayed org/dept, the panel on the right changes to show a message indicating that you do not have privileges to edit the information for that level.

Neither Rooms nor Users are subject to the organizational hierarchy except to the degree that an admin cannot create or grant rights to an admin above his/her own level of delegated access. Otherwise, these objects are visible and can be administered by all users with an admin role in the system.

Inherited vs explicitly set permissions

Understand that permissions are given from the top down, but not necessarily removed from the top down, once explicitly set at lower levels. The system assumes that if you have higher-level administrative permissions, you can automatically administer all items below that in the hierarchy. Lower levels inherit access from upper levels.

The first time you configure administrative access, removing upper-level permissions automatically clears all lower-level permissions for that user. But this is only true until you explicitly set admin access at a lower level. Once that is done, that node will inherit access but it will NOT inherit restriction or non-access (checkbox clearing) from the upper level. At this point, clearing the checkbox at the upper level only removes the check (access) for lower nodes that were never explicitly set. Once explicitly set at a lower level node, administrative privileges must also be explicitly removed from the lower-level node, if and when that is desired.

Basically, here is how it works:

• Any admin who has permission (box is checked) at the Institution level can see and administer all items in the system. All Admins have institution-level permissions by default.
• In order to limit access for an admin to an Org/Dept, you may need to disable (uncheck) admin access at the institution level first. The first time this is done for a user, this action CLEARS all permissions for all Organizations and Departments.
• You must enable (check) the user for admin access to the appropriate Organization or Department node(s). You have now explicitly enabled admin access to that node.
• If you enable admin access to an organization, that user can administer all items for the organization as well as for all departments within that organization.
• If you must delegate administrative rights to a user for multiple (but not all) departments within an organization, the user must be unchecked at the organization level, then checked for each department separately.
• If you ever need to revoke organization or department permissions, you must explicitly uncheck the user for the appropriate node(s). You cannot remove or "reset" explicitly set lower-level permissions by checking-then-unchecking the higher-level node. Any lower levels that were not checked before, retain the inherited setting; those that were explicitly checked must be explicitly unchecked.
• There is no way to delegate permissions for objects that reside in an organization only (no department) without also giving permissions to all departments within that organization. If this type of permission is needed, you must create a separate department to contain all of those objects, then give administration rights to that department.