This article explains Organization Roles in significant detail. We strongly encourage Tier 1 and 2 Administrators to take the time to read this article in its entirety; it contains almost everything you'd need to know about Organization Roles, and it explains how permissions and privacy rules are instantiated in the Engage platform. If you need to brush up on Organization Roles in the future, you can use the "cheat sheet" in the next article.
Recall the Organization map from the previous article:
In this example, Academia University is the Tier 1 Organization, the three colleges/schools are the Tier 2 Organizations, and the individual academic departments are the Tier 3 Organizations. Let's continue with this example as we explain some core notions pertaining to Yellowdig Organizations: Organization Roles, Organization Permissions, and Organization Visibility.
Each Yellowdig user has one or more Organization roles. There are three possible Organization Roles:
- Organization Administrator
- Organization Member
There are two types of Organization Members—Instructors and Non-Instructors—for reasons that will become apparent in the Organization Permissions section below.
Organization Roles are defined by what users can do (Permissions) and what users can find (Visibility). Users have Organization Roles relative to specific Organizations; hence, what users can do and find depends on their Role within a Organization or Organizations. For example, Administrators of the Academia University Organization have broader Permissions and Visibility than do Administrators of the College of Arts and Sciences (CAS) Organization, and Administrators of the CAS Organization have broader Permissions and Visibility than do Administrators of the Physics Department Organization.
You can think of Organization Roles as sets of rules governing how users can navigate their institution's interconnected Organizations. Organization Administrators have the greatest "freedom of movement", whereas Organization Guests have very limited mobility. Since Roles are Organization-specific, users' freedom of movement is determined both by the nature of the Role and by the user's "starting point": the Organization itself.
We make the notion a bit more concrete in the sections below. As you read, keep in mind this general principle for navigating Organizations: you can move inside and down, but not up and around. In other words, with respect to your Role in a Organization, you can move within the Organization, and you can move to that Organization's Sub-organizations; but you cannot move to a higher-tiered Organization, and you cannot move to a sibling Organization on the same tier. This principle will be illustrated repeatedly in what follows.
Organization Permissions determine what users can do in a Organization. More specifically, Organization Permissions determine (1) where users can read and write Community content, (2) where users can create Communities, and (3) where users can create Sub-organizations.
Organization Administrators can read and write content in Communities within their Organization and connected Sub-organizations. They can also create Communities and Sub-organizations within their Organization. In addition, they can promote any user to Administrator or Member status in their Organization.
Example: Administrators of the College of Business Organization can read and write content in College of Business Communities, in Finance Department Communities, and in Marketing Department Communities. They can also create Communities and Sub-organizations within the College of Business Organization and promote any user to Organization Administrator status. But they cannot read or write Community content, create Communities or Sub-organizations, or promote users to Administrator status in the Academia University Organization, in the CAS Organization, in the School of Law Organization, or in any subsidiary Organizations. In other words, Administrator privileges extend within and down, but not up and across.
Organization Members can read and write content in public Communities within their Organization and connected Sub-organizations. Instructors can create Communities through their LMS (e.g., Blackboard, Canvas), but not outside of it (assuming Community Creation is disabled for Organization Members). Non-Instructors cannot create Communities (again, assuming Community Creation is disabled for Organization Members).
Example: Members of the CAS Organization can read and write content in public Communities in the CAS Organization, in the Philosophy Department Organization, and in the Physics Department Organization. Members cannot read or write content in private Communities in the CAS Organization, in the Philosophy Department Organization, or in the Physics Department Organization without Community Owner permission. In addition, Members cannot create CAS Sub-organizations, promote users to CAS Administrator or Member, or create CAS Communities outside of their LMS. Member privileges extend within and down, but not up and across.
Organization Guests can only read and write content in Communities of which they are a Member. They cannot read or write content in other Communities (public or private), create Sub-organizations, or promote users. When you invite users directly to your Community outside of your LMS, they are automatically invited as Guests unless you specify otherwise. Organization Guests are an exception to the principle specified above: Guest privileges extend neither within nor down nor up nor across.
Below, we extend our Organization map to depict Permissions. As this map suggests, Organization Permissions generally hold within a Organization and down to its Sub-organizations, but not up to parent Organizations or across to sibling Organizations.
Organization Visibility determines what users can find in a Organization. More specifically, Organization Visibility determines (1) which Communities users can discover and (2) which Communities users can request to join.
Organization Administrators and Organization Members can discover Communities and request to join discoverable private Communities in their Organizations and Sub-organizations. Organization Members cannot discover or request to join Communities in parent or sibling Organizations, regardless of whether the Community in question is public or discoverable. Organization Administrators can find non-discoverable boards through the Organization Settings page (Edit Organization Settings → Communities). Organization Guests cannot discover or request to join any Communities, including Communities within their own Organization.
Visibility relationships mirror Permissions relationships. The map below is extended to include a Tier 2 Student Communities Organization where students create and administrate their own Communities, which we highly recommend for university-wide Yellowdig rollouts. (We explain our recommendation in Introduction to Organizations and Sub-organizations.)
Most Yellowdig users will have different Roles in multiple Organizations. For example, the Chair of the Marketing Department at Academia University might be a Member of the College of Business Organization and an Administrator of the Marketing Department Organization. As a Member of the College of Business Organization, the Chair would be able to discover Communities in the College of Business Organization and Sub-organizations and peruse public Communities in these Organizations. As an Administrator of the Marketing Department Organization, the Chair would be able to manage and monitor Marketing Department Communities, establish default settings for the Marketing Department Organization, promote colleagues to Organization Administrator status, and create Communities outside of LMS courses (e.g., a networking group for marketing students). At the same time, the Chair would not be able to poke around in Philosophy and Physics Communities or establish default settings for these Communities. Establishing Roles in this way gives department administrators the flexibility to manage their own departments without giving undue access to other departments. It is part of the reason we created Organizations in the first place.
Finally, consider another common use case. A student majoring in Philosophy and minoring in Physics might be a Member of the Philosophy Department Organization, a Member of the CAS Organization, and an Administrator of the Student Communities Organization. As a Member of both the Philosophy Department and CAS Organizations, this student can find discoverable Communities in both the Philosophy Department (e.g., Philosophy Club) and the Physics Department (e.g., Astrophysics Study Group). As an Administrator of the Student Communities Organization, the student can create her own Sub-organizations (e.g., Intramural Sports Clubs) and Communities (e.g., Intramural Basketball League), and she can choose to share administrative duties with her classmates. These student-run Organizations and Communities will be fully visible to Tier 1 Administrators at Academia University, and students will not be able to create Sub-organizations or Communities in any other Organization. We strongly recommend that Tier 1 Administrators enable the Student Communities Organization, thereby providing a monitored and tractable space for student-led engagement.