Data Identity Model

The short version

Keep using your existing unique IDs. The platform stores each one as an External ID and uses it to keep records matched to the right source record every time data is re-ingested. C3 identifiers are assigned later, during loading — you don't provide them.

What you provide

Provide the unique identifier you already use for each record in your source system:

• Associations — your association ID (e.g. A-12345)
• Units — your unit ID (e.g. U-67890)
• Members — your person/member ID (e.g. M-54321)
• Accounts — your account ID (e.g. ACC-9999)

These IDs must be unique within each entity type and stable across submissions.

What the platform does

1. Stores your ID as the record's External ID — the stable link back to your source system.
2. Uses the External ID to match records: the first time it sees an ID it creates the record; on a later ingestion it matches the same ID and updates the existing record — never a duplicate.
3. Assigns a C3 Id to each migratable record during the loading process (Phase 10 onward), as it moves into C3.

How the bridge works

Your record          →  External ID (the bridge)  →  C3 Id (assigned at load)
────────────────────────────────────────────────────────────────────────────
Association A-12345   →  external_id: "A-12345"    →  c3_id assigned during loading
Unit U-67890         →  external_id: "U-67890"    →  c3_id assigned during loading

Because the External ID is preserved end to end, a correction you make in the source system flows to the same record on the next ingestion, and that record carries the same C3 Id it was assigned at load.

Requirements

• Your IDs must be unique within each entity type.
• Your IDs must be consistent across all submissions.
• Your IDs should be strings (letters, numbers, dashes).

Don't change an ID between submissions, and don't reuse an ID for a different record — either breaks the bridge. You don't need to manage C3 Ids; they're assigned for you.

Quick reference