This article explains Network 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 Network Roles, and it explains how permissions and privacy rules are instantiated in the Engage platform. If you need to brush up on Network Roles in the future, you can use the "cheat sheet" in the next article.
Recall the Network map from the previous article:
In this example, Academia University is the Tier 1 Network, the three colleges/schools are the Tier 2 Networks, and the individual academic departments are the Tier 3 Networks. Let's continue with this example as we explain some core notions pertaining to Yellowdig Networks: Network Roles, Network Permissions, and Network Visibility.
Network Roles
Each Yellowdig user has one or more Network roles. There are three possible Network Roles:
- Network Administrator
- Network Member
- Network Guest
- Instructor
- Non-Instructor
There are two types of Network Members—Instructors and Non-Instructors—for reasons that will become apparent in the Network Permissions section below.
Network Roles are defined by what users can do (Permissions) and what users can find (Visibility). Users have Network Roles relative to specific Networks; hence, what users can do and find depends on their Role within a Network or Networks. For example, Administrators of the Academia University Network have broader Permissions and Visibility than do Administrators of the College of Arts and Sciences (CAS) Network, and Administrators of the CAS Network have broader Permissions and Visibility than do Administrators of the Physics Department Network.
You can think of Network Roles as sets of rules governing how users can navigate their organization's interconnected Networks. Network Administrators have the greatest "freedom of movement", whereas Network Guests have very limited mobility. Since Roles are Network-specific, users' freedom of movement is determined both by the nature of the Role and by the user's "starting point": the Network itself.
We make the notion a bit more concrete in the sections below. As you read, keep in mind this general principle for navigating Networks: you can move inside and down, but not up and around. In other words, with respect to your Role in a Network, you can move within the Network, and you can move to that Network's Subnetworks; but you cannot move to a higher-tiered Network, and you cannot move to a sibling Network on the same tier. This principle will be illustrated repeatedly in what follows.
Network Permissions
Network Permissions determine what users can do in a Network. More specifically, Network Permissions determine (1) where users can read and write Community content, (2) where users can create Communities, and (3) where users can create Subnetworks.
Network Administrators can read and write content in Communities within their Network and connected Subnetworks. They can also create Communities and Subnetworks within their Network. In addition, they can promote any user to Administrator or Member status in their Network.
Example: Administrators of the College of Business Network 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 Subnetworks within the College of Business Network and promote any user to Network Administrator status. But they cannot read or write Community content, create Communities or Subnetworks, or promote users to Administrator status in the Academia University Network, in the CAS Network, in the School of Law Network, or in any subsidiary Networks. In other words, Administrator privileges extend within and down, but not up and across.
Network Members can read and write content in public Communities within their Network and connected Subnetworks. Instructors can create Communities through their LMS (e.g., Blackboard, Canvas), but not outside of it (assuming Community Creation is disabled for Network Members). Non-Instructors cannot create Communities (again, assuming Community Creation is disabled for Network Members).
Example: Members of the CAS Network can read and write content in public Communities in the CAS Network, in the Philosophy Department Network, and in the Physics Department Network. Members cannot read or write content in private Communities in the CAS Network, in the Philosophy Department Network, or in the Physics Department Network without Community Owner permission. In addition, Members cannot create CAS Subnetworks, 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.
Network 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 Subnetworks, 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. Network Guests are an exception to the principle specified above: Guest privileges extend neither within nor down nor up nor across.
Below, we extend our Network map to depict Permissions. As this map suggests, Network Permissions generally hold within a Network and down to its Subnetworks, but not up to parent Networks or across to sibling Networks.
Network Visibility
Network Visibility determines what users can find in a Network. More specifically, Network Visibility determines (1) which Communities users can discover and (2) which Communities users can request to join.
Network Administrators and Network Members can discover Communities and request to join discoverable private Communities in their Networks and Subnetworks. Network Members cannot discover or request to join Communities in parent or sibling Networks, regardless of whether the Community in question is public or discoverable. Network Administrators can find non-discoverable boards through the Organization Settings page (Edit Organization Settings → Communities). Network Guests cannot discover or request to join any Communities, including Communities within their own Network.
Visibility relationships mirror Permissions relationships. The map below is extended to include a Tier 2 Student Communities Network where students create and administrate their own Communities, which we highly recommend for university-wide Yellowdig rollouts. (We explain our recommendation in Introduction to Networks and Subnetworks.)
Managing Multiple Roles
Most Yellowdig users will have different Roles in multiple Networks. For example, the Chair of the Marketing Department at Academia University might be a Member of the College of Business Network and an Administrator of the Marketing Department Network. As a Member of the College of Business Network, the Chair would be able to discover Communities in the College of Business Network and Subnetworks and peruse public Communities in these Networks. As an Administrator of the Marketing Department Network, the Chair would be able to manage and monitor Marketing Department Communities, establish default settings for the Marketing Department Network, promote colleagues to Network 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 Networks 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 Network, a Member of the CAS Network, and an Administrator of the Student Communities Network. As a Member of both the Philosophy Department and CAS Networks, 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 Network, the student can create her own Subnetworks (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 Networks and Communities will be fully visible to Tier 1 Administrators at Academia University, and students will not be able to create Subnetworks or Communities in any other Network. We strongly recommend that Tier 1 Administrators enable the Student Communities Network, thereby providing a monitored and tractable space for student-led engagement.