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 have the option to assign those to an organization and/or a department. You don't have to group courses under an organization or department, but for larger deployments 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.
To allow for distributed responsibilities for managing different items within the system, Echo360 allows you to turn on Delegated Administration, then select which Administrator users have access to objects at different hierarchical levels. You are able to delegate administration to different departments, organizations, or to the institution.
Delegated administration effectively allows or restricts access to objects 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.
BY DEFAULT, all administrators can access all aspects of the system. You must remove the default "institution level" access, which removes all lower-level administrative access. Then you can explicitly enable administrative access to the appropriate organizations and/or departments.
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.
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 with institution-level access; departments can only be created with organization-level access.
The ability to create users with hierarchical privileges above their own. In fact, if Delegated Administration is turned on, ALL NEW ADMIN USERS MUST have hierarchical rights explicitly granted. Otherwise these users will not see any courses/sections or captures in the UI.
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.
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. Rooms assignment to specific hierarchical levels is a feature to be implemented shortly.
To enable and set delegated administration:
Depending on the number of users in your system as well as the number of Admin-role users, the system may take several seconds to display the options on the right side of the page. We are aware of this issue and are addressing it.
NOTE: Enabling access for an Organization automatically enables access to all departments. To enable rights for some departments but not others in the Organization, you must uncheck the user for the organization first, then enable the user for the individual departments. See Inherited vs. explicitly set permissions below.
You should never see your own name in an admin list; you cannot change your own 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 must 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.
IMPORTANT: If you have objects in the system that are not assigned to an organization or department, only administrators with Institution-level admin permissions will have access to those objects. You may need to assign or re-assign items within your system accordingly.