Entity Model

The full catalog lives in the Entity Explorer

This page explains how the entities fit together conceptually. For the authoritative, always-current list of every entity, its fields, and its validation rules, use the Entity Explorer — it is generated directly from the live schema, so it never drifts out of date.

Association is the root

The association is the root of the data model. Every other entity — units, accounts, members, financials, vendors — carries a reference back to an association. Because everything depends on associations, they are ingested first, establishing the foundation for all subsequent work.

Load order

Entities are ingested in dependency order: an entity can only load once the entities it references already exist. The groups, in order:

1. Associations — the root entity, plus its per-association configuration entities (see below).
2. Regions → Locations — geographic access hierarchy.
3. Unit Types → Units — property hierarchy.
4. Accounts, Account Units, Account Addresses — depend on units.
5. Organization Members → Association Members → Account Members — the people hierarchy.
6. Owners, Tenants, Occupants (account-level roles); Board Members, CAMs, Emergency Contacts (association-level roles).
7. Banks → Bank Accounts → Investment Bank Accounts, Direct Debits — financial accounts; banks is the organization-level institution master.
8. Recurring Charges — depend on accounts and unit types.
9. GL Accounts, Charge Types, Delinquency Statuses, Reimbursables — the mappable entities, standardized during Standardization.
10. Account Transactions, Account Notes — depend on accounts and charge types.
11. Vendors → Association Vendors — vendor relationships.
12. Tracked Items — optional / supplemental.

Source, mapped, and standard tiers

The four mappable entities — GL accounts, charge types, delinquency statuses, and reimbursables — exist in three tiers:

• Source — the records as they came from the branch's source system.
• Standard — Associa/C3 reference data (the target codes to map onto).
• Mapped — the link between a source record and the standard code it maps to. The mapped records are the canonical output that the C3 loading pipelines consume.

Standardization (Phase 6) is the work of populating the mapped tier. See Standardization for how this works, including the global vs. association mapping tiers.

Configuration entities are ingested

Each association carries two per-association configuration entities that describe how it operates:

• Billing configuration — billing method, coupon settings, and related billing parameters.
• Delinquency configuration — the association's delinquency process configuration.

These are ingested along with the rest of the data, not configured in the app. The app surfaces them read-only under Review — see Data Availability & Configuration. Fiscal-year start and end months are ingested as columns on the association itself, and GL periods are generated by the pipeline.

The migration lifecycle

Migration progress is tracked entity by entity, per wave. Each entity advances through a fixed lifecycle:

Field Mapped → Ingested → Data Quality Reviewed → Standardized → App Validated → C3 UAT Loaded → C3 UAT Validated → C3 Prod Loaded

Transitions are fully manual — a person advances an entity's state once the corresponding work is verifiably complete. See Migration Tracking & Sign-off for what each state means and how sign-off works.