At its core, Registry a system for managing data records of various types. Under the hood, everything just looks like a database table, so it may be helpful to logically group these records.

Primary Objects

Primary Objects are those that represent the main records that Registry is designed to manage. In general, Primary Objects represent real world things. (These also tend to be the focus of the Registry Data Model.) Primary Objects are

• CO Person, the operational record for people associated with the CO.
• CO Department, intended to represent organizational structure within the CO.
• CO Email List.
• CO Group.
• CO Service.
• Organization, intended to represent entities outside the CO.
• Servers (of various types).

Secondary Objects

Secondary Objects generally provide additional data associated with a Primary Object. Secondary Objects typically have a many-to-one relationship to Primary Objects, in order to allow for multiple values. As an example, a CO Person can have many Names. Secondary Objects include

• Address
• CO Person Role
• Email Address
• Identifier
• Name
• Org Identity*
• TelephoneNumber
• URL

*Organizational Identities are treated as Primary Objects, however beginning with Registry v5.0.0 changes will be implemented that clarify their actual positions as Secondary Objects.

Configuration Objects

Configuration Objects govern how Registry operates, either across the platform or within a given CO. Primary and Secondary Objects might have direct foreign key relationships to Configuration Objects, or their management may be indirectly governed by them. Important Configuration Objects include

• ApiUser, which determines how API access is governed. API Users are considered Configuration, not Primary.
• CO, the tenant of the multi-tenant platform.
• COU, a mechanism for governing population management within the CO.