Child pages
  • Representing Organizational Hierarchy Through COUs and Departments
Skip to end of metadata
Go to start of metadata

Overview

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.

Collaborative Organizational Units (COUs)

COUs have a hierarchical relationship within a CO, much in the same way LDAP OUs have a hierarchical relationship within an O.

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 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).

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 and the Service Portal.

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 and 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.

Comparison Summary


COUCO DepartmentCO Group
Object TypeStructural ObjectPrimary Registry ObjectPrimary Registry Object
Belongs To
  • CO
  • CO
  • COU
  • CO
  • COU (for automatic groups only)
Has Many
  • CO Person Roles
  • CO Departments

  • CO People (via CoGroupMember)
  • CO Email List
HIerarchicalYesNo (CO-1523)No (CO-721)
Supported AttributesNone
  • Addresses
  • Email Addresses
  • Identifiers
  • Telephone Numbers
  • URLs
  • Leadership Group
  • Administrative Group
  • Support Group
  • Open / Closed
  • Managers (via CoGroupMember)
  • Email Addresses (via CoEmailList)
  • Identifiers (as of Registry v3.3.0)



  • No labels