diff --git a/_episodes/02-generalFactors.md b/_episodes/02-generalFactors.md
index 33e2d33..83aa2d6 100644
--- a/_episodes/02-generalFactors.md
+++ b/_episodes/02-generalFactors.md
@@ -16,6 +16,8 @@ Review in broad strokes the factors that may affect how you model your organizat
 
 COmanage is a multi-tenet tool. This means that for each installation, one or more top-level groups can be expressed. These groups are called Collaborative Organizations or COs. Individuals are added to these fundamental groups (COs), but once there, the individuals can be included in multiple sub groups of the CO, called Collaboration Organization Units (or COUs.)
 
+As a collaboration grows in size, it may be useful to create various structures to allow for delegation of person management operations and representation of organizational hierarchy. COmanage Registry supports this through the concept of CO Units, or COUs. As of Registry v3.1.0, CO Departments are also supported.
+
 ### The COs
 
  The term “Collaborative Organization” or CO to refer to any formal or informal group of individuals that work collaboratively in a digital setting. They have a goal of a shared infrastructure that supports their collaborations so that the traditional limitations of localized applications may be overcome. Some traits of these COs include:
@@ -39,8 +41,39 @@ If your collaboration–a single entity with common goals–has unique requireme
 
 When you have COUs, they may represent recognized groups of collaborators like departments, divisions, projects; or they may be related to the privileges that those in the group may have, for example, alumni or parents. 
 
+COUs are a structural object within Registry, meaning they can be configured, and that they are used internally for a variety of purposes. The primary purpose of a COU, however, is to allow for delegation of person management operations. [COU Administrators](https://spaces.at.internet2.edu/display/COmanage/Registry+Administrators) can be defined for each COU, giving them the ability to perform lifecycle management operations on the CO People who have CO Person Roles associated with the COU that they manage (or any child COUs of that COU).
+
+If COUs are defined, they can be flat (no hierarchy, all are at the same level), or a COU can have a parent COU (in which case a hierarchy is implied).
+
 > A COU relationship to a CO is similar to the way that LDAP OUs have a relationship within an O.
 
+### CO Departments
+
+CO Departments are primary objects within Registry, which means that they are intended to store representations of external objects (just like CO People). CO Departments can attach to either a CO or a COU, and can be used to store a number of attributes about the department, including telephone numbers, email addresses, URLs, identifiers, and the sets of people associated with specific responsibilities within the department. CO Departments can be used to support various use cases:
+
+In a VO deployment, CO Departments can be used to represent research groups.
+In an enterprise deployment, CO Departments can be used to represent the University department hierarchy.
+While there may typically be a one-to-one relationship between CO Departments and COUs, it is not strictly necessary. For example, a COU maybe made up of members spanning two departments.
+
+CO Departments are visible to anyone within the CO, by logging in to Registry, though only CO Administrators may edit their information.
+
+CO Departments are specifically intended to be used with [Registry Services](https://spaces.at.internet2.edu/display/COmanage/Registry+Services) and the Service Portal.
+
+### CO Groups
+
+There is also a structure called CO Groups - these are explored in depth in Lesson 306.
+
+#### COUs vs CO Groups
+
+The major differences between COUs and CO Groups are
+
+* Any CO Person can create a CO Group; only CO Administrators can create COUs.
+* CO Group Memberships attach at the CO Person level, whereas COU memberships attach at the CO Person Role level.
+* Management of CO Group Memberships is simple (e.g., manual management by the CO Group Owner, self-opt in for open CO Groups, etc.), whereas COU memberships can be managed using [Enrollment Flows](https://spaces.at.internet2.edu/display/COmanage/Registry+Enrollment+Flow+Configuration) and [Expiration Policies](https://spaces.at.internet2.edu/display/COmanage/Expiration+Policies).
+* COU memberships imply CO Group Memberships (in the _Members:COU group_).
+* Email Addresses can be attached to CO Groups via [CO Email Lists](https://spaces.at.internet2.edu/display/COmanage/CO+Email+Lists).
+
+
 #### An example - LIGO
 
 LIGO is a virtual organization with a concrete goal (discovering gravitational waves) and specific large equipment (the detectors) to help reach that goal. LIGO, however, is not a uniform, flat organization. Within LIGO, there are several smaller organizations. These smaller organizations have specific needs regarding how new people join in their groups, and yet, these smaller organizations all have something in common - the parent organization of LIGO, where access to the equipment and the data is controlled, where agreements may be signed with new organizations wanting to be a part of (or a partner of) LIGO.