Screen shots - How to additions

_episodes/02-cous.md

@@ -10,85 +10,113 @@ keypoints:
 - "List the key takeaways for the episode"
 ---
 
+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 supports this through the concept of Collaborative Organization Units (COUs), or COUs. COs can support one or more COUs.
+
 # 2. Collaborative Organization Units (COUs)
 
-"Collaborative Organizations Units" allow you to define an organizational structure within a CO. While many organizations have natural groups within them, the reason that you would divide your CO into COUs are because there are differences across your CO that necessitates different policies in one or more of the following:
+Collaborative Organizations Units (or `COUs`:gear:) allow you to define an organizational structure within a CO. While many organizations have natural groups within them, the reason that you would divide your CO into COUs are because there are differences across your CO that necessitates different policies in one or more of the following:
 
 * How individuals join and/or leave the group
 * There are different rules about how applications get provisioned or deprovisioned
 * Who manages person membership and privileges in the group
 * The information stored or used about members of the group 
 
-If your collaboration–a single entity with common goals–has unique requirements among the different groups and/or departments regarding how participants will join those parts of your collaborations, then, you have a CO that contains COUs. If you have only one common set of policies that define how individuals are added or removed from the CO, then you do not have COU even though you may have groups for simple access control.
+If your collaboration–a single entity with common goals–has unique requirements among the different groups and/or departments regarding how participants will join those parts of your collaborations, then, you have a CO that contains COUs. If you have only one common set of policies that define how individuals are added or removed from the CO, then you do not have COUs even though you may have groups for simple access control.
+
+When you have `COUs`:gear:, 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. The primary purpose of a `COUs`:gear:, however, is to allow for delegation of person management operations. 
 
-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. 
+If `COUs`:gear: are defined, they can be associated directly with the `CO`:gear: or they can have another `COU`:gear: as a parent.
 
-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).
+# `CO Person Roles`:gear: - a.k.a., associating `CO Persons`:gear: with `COUs`:gear:
 
-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).
+Any `CO Person`:gear: in the `CO`:gear: can be part of any of the `COUs`:gear: in the `CO`:gear:. This connection happens through an object called a `CO Person Role`:gear:.
 
-> A COU relationship to a CO is similar to the way that LDAP OUs have a relationship within an O.
+The attributes (information) stored in the `CO Person Role`:gear: object typically includes
 
+* Link to the associated `CO Person`:gear: who is connected to the `COU`:gear:
+* Link to the person who is sponsoring the `CO Person`:gear:. `Sponsors`:gear: are usually used in relation to guest systems. We'll talk more about `Sponsors`:gear: later.
+* Status
+* Personal information about the person
+  * Date of birth
+  * affiliation (eduPerson)
+  * organization, department, & title
+* List of physical addresses / phone numbers
 
-# CO Person Role Status
+These roles also can include information about the percent time the registered person is allocated to this role.
 
-As with the :gear: `CO Person` object, each :gear: `CO Person Role` object
+`CO Persons`:gear: can have any number of `CO Person Roles`, usually one for each `COU` that the person is part of.
 
-## Calculated status value
+## CO Person Role Status
 
-Calculating the :gear: `CO Person` status from those of the :gear: `CO Person Role` object
+As with `CO Persons`:gear:, each `CO Person Role`:gear: has a status related to it. The list of possible values is identical to that we reviewed in the previous lesson.
 
-Each CO Person Role has a status attached to it and each CO Person has an overall status that is generally calculated as the "most preferred" of the attached CO Person Role statuses. Statuses represent various states in the identity lifecycle, and various statuses have specific meanings within COmanage.
+When a `CO Person`:gear: is connected to one or more `CO Person Roles`:gear:, the status of the `CO Person` is calculated from that of the associated Roles based on the "most preferred" status. "Most preferred" is currently defined as the order in the status table (repeated here from the discussion about `CO Person` status in the previous lesson.) 
 
-Status can be changed under various circumstances:
+Active statuses are most preferred, followed by expired statuses, followed by invitation statuses.
 
-* As part of Enrollment or Invitation. (Onboarding)
-* As part of an Organizational Identity Source and Pipeline sync.
-* Due to an Expiration Policy. (Offboarding)
-* By updating CO Person Role validity dates.
-  * If a Role is in Pending status and the Valid From date is updated to be in the past, the Role will automatically change to Active status.
-  * If a Role is in Active status and the Valid From date is updated to be in the future, the Role will automatically change to Pending status.
-  * If a Role is in Expired status and the Valid Through date is updated to be in the future, the Role will automatically change to Active status.
-  * If a Role is in Active or Grace Period status and the Valid Through date is updated to be in the past, the Role will automatically change to Expired status.
-* Manually. Note that manual changes will be overwritten when an automatic update would result in a different status.
+Preference | Status | Description
+---------- | ------ | -----------
+1 | Active | Person or Role is an active member of the organization or collaboration
+2 | GracePeriod | Primary association with the organization has ended, but services have not yet been deprovisioned
+3 | Suspended | Association with the organization has been (manually) temporarily suspended
+4 | Expired | Valid through date has been reached
+5 | Approved | 
+6 | PendingApproval | The enrollment flow petition is pending approval
+7 | Confirmed | 
+8 | PendingConfirmation | An invitation or email confirmation was sent via an enrollment flow 
+9 | Invited | An invitation was sent via default enrollment 
+10 | Pending | 
+11 | Denied | The enrollment flow petition was denied 
+12 | Declined | The invitation sent via default enrollment was declined 
+13 | Deleted | 
+14 | Duplicate | The record is a duplicate of another 
+
+# Administrator Roles
 
-The status of a CO Person is generally calculated from the status of the CO Person Roles attached. This happens automatically under the following conditions:
+## `COU Administrators`:crown:
 
-* When a CO Petition is approved/the Enrollee becomes active.
-* When an Expiration Policy changes the status of a CO Person Role.
-* When updating a CO Person Role Valid Through date causes the CO Person Role to become Active.
-* When a Pipeline results in a status change.
-* When a CO Person Role status is manually changed.
+`COU Administrators`:crown: can be defined for each `COU`:gear:, giving them the ability to perform lifecycle management operations on the `CO People`:gear: who have `CO Person Roles`:gear: associated with the COU that they manage.
+
+Unit Administrators have limited privileges within the CO, generally related to the ability to enroll and manage populations within the CO Unit (COU).
+
+Unit Administrators are configured by adding the appropriate Organizational Identity to the CO (if not already done), and then adding the corresponding person to the _CO:COU:COU-Name:admins_ group (v2.0.0 and later) or _admin:COU-Name_ group (prior to v2.0.0) within the CO.
 
-The CO Person status is set to the "most preferred" status of the attached CO Person Roles. "Most preferred" is currently defined as the order in the table, below. In general, active statuses are most preferred, followed by expired statuses (since there may have been skeletal records provisioned that need to be maintained), followed by invitation statuses.
+# About Sponsors
 
-CO Person and Person Role Records are passed to Provisioners based on their status, as indicated in the table, below.
 
 # Administrator Roles
 
 COmanage Registry defines three types of administrators.
 
 ## Unit (COU) Administrators
 
-Collaboration Administrators with sophisticated administrative requirements may optionally define Unit Administrators. Unit Administrators have limited privileges within the CO, generally related to the ability to enroll and manage populations within the CO Unit (COU).
-
-Unit Administrators are configured by adding the appropriate Organizational Identity to the CO (if not already done), and then adding the corresponding person to the _CO:COU:COU-Name:admins_ group (v2.0.0 and later) or _admin:COU-Name_ group (prior to v2.0.0) within the CO.
+Collaboration Administrators with sophisticated administrative requirements may optionally define Unit Administrators. 
 
 COU 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).
 
 
 ---
 
-< TO BE UPDATED >
-
 # Terminology & resources
 
-## COmanage Objects
+## COmanage Objects :gear:
 
 OBJECT | DESCRIPTION
 ------ | -----------
-`CO Person` :gear: | the representation of a person in COmanage
-`CO Group` :gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons` :gear:
+`CO`:gear: | 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.
+`CO Person`:gear: | the representation of a person in COmanage
+`Identity Source`:gear: | Information about a person as obtained from an external source such as LDAP, netFORUM or ORCID. 
+`CO Person Role`:gear: | the representation of a person's role in COmanage. This object describe the person's role with certain collections of people within your organization or collaboration. These objects are attached to :gear: `CO Person` objects; there may be any number of Roles.
+
+`CO Group`:gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons`:gear:
+
+## CO Person Roles :crown:
+
+ROLE | DESCRIPTION
+---- | -----------
+`CMP Administrators`:crown: | CMP Administrators are effectively super users, with the ability to perform almost all operations on the platform.
+`CO`:gear: Administrators | `CO`:gear: Administrators are super users _within a CO_.
+`System Administrators`:crown: | System Administrators have privileges that enable them to maintain the COmanage application.
 
 ## Worksheets
 

index.md

@@ -3,14 +3,14 @@ layout: lesson
 root: .
 ---
 
-A key decision that you will need to make when setting up COmanage is how you will model your organization, project or collaboration. Thoughtful consideration will both provide both significant built-in capabilities, as well as flexibility as you use information created and managed in COmanage with other systems and services. 
+# CO320 - Modeling Organizational Structures in COmanage
 
-In this lesson, you will learn what to consider when modeling your collaboration in COmanage, how to express this model, and how to make adjustments when needed.
+When using COmanage with your organization or collaboration, the people that you have registered will naturally fall into groups, perhaps by organizational unit, project team, or the activities that a group of people can do. In this lesson, you will learn how these structures are modeled within COmanage and understand which structures to use to meet your needs.
 
 **WHO IS THIS COURSE FOR?** Application administrators.
 
 > ## Prerequisites
-> CO102 or CO103 or equivalent
+> [CO101: Getting to Know COmanage](https://github.internet2.edu/lpaglione/COmg-CO101-intro) or equivalent
 
 > ## Top Things You Need To Know
 >
@@ -25,19 +25,10 @@ In this lesson, you will learn what to consider when modeling your collaboration
 Time | Section | Description
 ---- | ------- | -----------
   | [Setup](/setup.md) | Prepare for the lesson
-00:20 | 1. [The benefits of good modeling](/episodes/modelingBenefits.md) | Why is this important? What does good modeling get you? What challenges can result from poor modeling?
-00:00 | 2. [Understanding the factors that may affect your modeling](/episodes/generalFactors.md) | Review in broad strokes the factors that may affect how you model your organization, project or collaboration. Explore some real-world examples.
-00:00 | 3. [Considering the factors for your situation](/episodes/yourFactors.md) | Using the modeling worksheet you will consider your own organization, project or collaboration and the factors that may affect its model within COmanage.
-00:00 | 4. [Picking a model](/episodes/yourModel.md) | Working collaboratively with others in the class, choose a model that you think would work for your situation.
-00:00 | 5. [Modeling within COmanage](/episodes/generalCous.md) | Learn about Collaboration Organization Units (COUs), and how they are used to express a model in COmanage.
-00:00 | 6. [Express your model with COUs](/episodes/yourCous.md) | Using the model that you have picked, express it in COmanage.
-00:00 | 7. [Making changes](/episodes/changesHappen.md) | It's impossible to anticipate all needs. How do you adjust your model when necessary?
-00:00 | 8. [Advanced Topics](/episodes/advanced.md) | During this section we will review advanced topics of interest to the class. Some examples include: <list to come>
+00:45 | [1. The CO](/_episodes/01-co.md) | Collaborative Organizations, what they are and how they are used.
 
 _The actual schedule may vary slightly depending on the topics and exercises chosen by the instructor._
 
-
-1. [1. The CO](/_episodes/01-co.md) - Collaborative Organizations, what they are and how they are used
 2. [2. The COUs](/_episodes/02-cous.md) - CO Units
 3. [3. About CO Departments](/_episodes/03-departments.md) - 
 4. [4. About CO Groups](/_episodes/04-groups.md)