Before continuing, make sure you are familiar with Registry People Types.

A given individual can have more than one Organizational Identity, and a given Organizational Identity can be affiliated with more than one CO Person. COmanage Registry can manage these relationships in different ways, according to how you design your platform.

By default, Organizational Identities are attached to the COs they are enrolled within ("unpooled"). This means that if CO #1 and CO #2 both want to know about Pat Lee at Central University, each CO will have it's own copy of Pat Lee's Central University Organizational Identity. The reason for this is that COmanage Registry assumes, in a federated identity context, that attribute release policies between Central University and CO #1 are not the same as for attribute release policies between Central University and CO #2. For a multi-tenant deployment, this is almost certainly the correct option.

However, if Central University's attribute release policy applies to the entire platform, and not directly to the COs on a platform, Organizational Identities can (and should) be pooled. In this model, Pat Lee will have a single Central University Organizational Identity record, and both CO #1 and CO #2 will refer to it. This means, for example, that is Pat Lee's attributes have changed, as soon as they are updated (whether manually, at login time, or by some other means) the updated values will be available to all COs. It also means that any CO can see all Organizational Identities created by any other CO.

As of COmanage Registry v1.0.0, this setting must be selected when the platform is first set up. It is not possible to change the setting once selected.

The correct option for you will depend on the relationship model between your platform and your COs. If you're not sure which setting is best, most likely you want to leave Organizational Identities unpooled.