The EchoVideo 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 EchoVideo 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, 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. Orgs/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.

Designated Administration is just that; the ability to designate 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

Designated administration effectively allows or restricts access to courses/sections and features based on their association with a level in the hierarchy. This means that an Admin who is given rights to only Departments 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 Designated 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.

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

Create terms across the institution.
Access to the institution configuration pages.
The ability to manage devices across the institution via the Rooms tab.
Allow data exports from the Imports/Exports tab.
Require the Org/Dept when scheduling captures.
Access to all published and/or unpublished content across organizations.
The ability to create and delete users.

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 designated 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 Admin 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.

Institution settings page with Organization selected and showing Administrators list for that level as described

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 designated 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 expressly 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.
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 designate administrative rights to a user for multiple (but not all) departments within an organization, the user must be unchecked at the organization level and 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 and then un-checking 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 designate 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, and then give administration rights to that department.