Client ID | First Name | Last Name | Date Update From Source | Parent ID | SourceSystemID | Deleted | DedupID |
1234 | Surya | Yadavalli | 04-05-16 | | cli_111 | | 123abc |
v2014
Client ID | First Name | Last Name | Deleted | Schema Year | DedupID |
1234 | Surya | Yadavalli | | 2014 | 123abc |
ABCD | Eric | Jahn | | 2015 | xyz456 |
base
Client ID | First Name | Last Name | Date Update From Source | Parent ID | SourceSystemID | Deleted | DedupID |
ABCD | Eric | Jahn | 04-08-16 | | cli_222 | | xyz456 |
v2015
Simple scenario where clients are inserted via bulk uploader or API POST and are assigned a DedupID.
Description: user data collection event #1 (API or bulk upload) resulted in a client 1234 which is tied to Enrollment abc111 and user data collection event #2 (API or bulk upload) resulted with another client ABCD.
v2014
EnrollmentID | clientID | Date Update From Source | Enrollment Date | Parent ID | SourceSystemID | Deleted |
abc111 | 1234 | 04-06-16 | 04-06-16 | | cli_111 | |
Client ID | First Name | Last Name | Parent ID | Deleted | Dedup_id |
1234 | Surya | Yadavalli | | | 123abc |
v2014
Client ID | First Name | Last Name | Deleted | Schema Year | DedupID |
1234 | Surya | Yadavalli | | 2014 | 123abc |
ABCD | Eric | Jahn | | 2015 | xyz456 |
base
Client ID | First Name | Last Name | Date Update From Source | Parent ID | SourceSystemID | Deleted | DedupID |
ABCD | Eric | Jahn | 04-08-16 | | cli_222 | | xyz456 |
v2015
Continuing from the state of the last slide, now, we have a third user event (#3). The user collects a new record (API POST of bulk upload). A match was found for a client in v2014 schema uploaded during user event #2:
Same client with same dedup ID.
We update in this case since the date_updated from source for the to-be inserted clientID (06-05-16) is later than the preexisting matching clientID (04-05-16). The new record gets the old record’s id. The ParentID keeps the history intact.
Client ID | First Name | Last Name | Date Update From Source | ParentID | SourceSystemClientID | Deleted | DedupID |
1235 | Surya | Yadavalli | 04-05-16 | 1234 | cli_111 | | 123abc |
1234 | Surya | Yadavalli | 06-05-16 | | cli_222 | | 123abc |
v2014
EnrollmentID | clientID | DateUpdateFromSource | Enrollment Date | Parent ID | SourceSystemEnrollmentID | Deleted |
abc111 | 1234 | 04-06-16 | 04-06-16 | | enrll_111 | |
Client ID | First Name | Last Name | Parent ID | Deleted | Dedup_id |
1234 | Surya | Yadavalli | | | 123abc |
v2014
Client ID | First Name | Last Name | Deleted | Schema Year | DedupID |
1234 | Surya | Yadavalli | | 2014 | 123abc |
ABCD | Erik | John | | 2015 | xyz456 |
base
Client ID | First Name | Last Name | Date Update From Source | Parent ID | SourceSystemID | Deleted | DedupID |
2222 | Eric | Jahn | 04-08-16 | ABCD | cli_222 | | xyz456 |
ABCD | Erik | John | 06-06-16 | | cli_111 | | xyz456 |
v2015
Continuing from the state of the last slide, now, we have a fourth user event (#4). User updates the client (ID ABCD) using v2015 schema (PUT) or bulk uploader match of same ID and a later date_updated
Existing record will be cloned. And a new record will be inserted in v2015 schema (Note that the new record will have the Parent ID referring to the older record)
Base schema will have the latest data with the updated information of the client.
Client ID | First Name | Last Name | Date Update From Source | ParentID | SourceSystemID | Deleted | DedupID |
1235 | Surya | Yadavalli | 04-05-16 | 1234 | cli_111 | | 123abc |
1234 | Surya | Yadavalli | 06-05-16 | | cli_222 | | 123abc |
v2014
EnrollmentID | clientID | DateUpdateFromSource | Enrollment Date | Parent ID | SourceSystemEnrollmentID | Deleted |
abc111 | 1234 | 04-06-16 | 04-06-16 | | enroll_111 | |
Client ID | First Name | Last Name | Parent ID | Deleted | Dedup_id |
1234 | Surya | Yadavalli | | | 123abc |
v2014
Client ID | First Name | Last Name | Deleted | Schema Year | DedupID |
ABCD | Erik | John | | 2015 | xyz456 |
base
Client ID | First Name | Last Name | Date Update From Source | Parent ID | SourceSystemID | Deleted | DedupID |
2222 | Eric | Jahn | 04-08-16 | ABCD | cli_222 | | xyz456 |
ABCD | Erik | John | 06-06-16 | | cli_111 | | xyz456 |
v2015
Continuing from the state of the last slide, now, we have a fifth user event (#5). User deletes the client (ID 1234) using v2014 schema (DELETE), or with a delete=”true” attribute in XML or CSV 4.0.x. Either way…
DELETED flag in v2014 schema for the client record will be set to TRUE. Deletion cascades down to anything referencing this clientID, which in this case is the EnrollmentID and maybe its children. Client record (ID 1234) will be deleted from Base schema.
Client ID | First Name | Last Name | Date Update From Source | ParentID | SourceSystemID | Deleted | DedupID |
1235 | Surya | Yadavalli | 04-05-16 | 1234 | cli_111 | | 123abc |
1234 | Surya | Yadavalli | 06-05-16 | | cli_222 | true | 123abc |
v2014
EnrollmentID | clientID | DateUpdateFromSource | Enrollment Date | Parent ID | SourceSystemEnrollmentID | Deleted |
abc111 | 1234 | 04-06-16 | 04-06-16 | | enroll_111 | true |
Client ID | First Name | Last Name | Parent ID | Deleted | Dedup_id |
1234 | Surya | Yadavalli | | | 123abc |
v2014
Client ID | First Name | Last Name | Deleted | Schema Year | DedupID |
base
Client ID | First Name | Last Name | Date Update From Source | Parent ID | SourceSystemID | Deleted | DedupID |
2222 | Eric | Jahn | 04-08-16 | ABCD | cli_222 | | xyz456 |
ABCD | Erik | John | 06-06-16 | | cli_111 | true | xyz456 |
v2015
Continuing from the state of the last slide, now, we have a sixth user event (#6). User deletes the client (ID ABCD) using v2015 schema (DELETE), or with a delete=”true” attribute in XML or CSV 4.1x. Either way…
DELETED flag in v2015 schema for the client record will be set to TRUE. Deletion cascades down to anything referencing this clientID, which in this case is nothing. Client record (ID ABCD) will be deleted from Base schema.
Client ID | First Name | Last Name | Date Update From Source | ParentID | SourceSystemID | Deleted | DedupID |
1235 | Surya | Yadavalli | 04-05-16 | 1234 | cli_111 | | 123abc |
1234 | Surya | Yadavalli | 06-05-16 | | cli_222 | true | 123abc |
v2014
EnrollmentID | clientID | DateUpdateFromSource | Enrollment Date | Parent ID | SourceSystemEnrollmentID | Deleted |
abc111 | 1234 | 04-06-16 | 04-06-16 | | enroll_111 | true |
Client ID | First Name | Last Name | Parent ID | Deleted | Dedup_id |
1234 | Surya | Yadavalli | | | 123abc |
v2014
Client ID | First Name | Last Name | Deleted | Schema Year | DedupID |
base
Client ID | First Name | Last Name | Date Update From Source | Parent ID | SourceSystemID | Deleted | DedupID |
2222 | Eric | Jahn | 04-08-16 | ABCD | cli_222 | | xyz456 |
ABCD | Erik | John | 06-06-16 | | cli_111 | true | xyz456 |
v2015
GET /clients on *each of* v2014 and v2015 returns all the clients where PARENT ID is NULL (latest record) and DELETED is NOT true (not deleted), so in this case, none are returned.
Client search returns all the records from base schema matching the criteria, so in this case, none are returned.
Client ID | First Name | Last Name | Date Update From Source | ParentID | SourceSystemID | Deleted | DedupID |
1235 | Surya | Yadavalli | 04-05-16 | 1234 | cli_111 | | 123abc |
1234 | Surya | Yadavalli | 06-05-16 | | cli_222 | true | 123abc |
v2014
EnrollmentID | clientID | DateUpdateFromSource | Enrollment Date | Parent ID | SourceSystemEnrollmentID | Deleted |
abc111 | 1234 | 04-06-16 | 04-06-16 | | enroll_111 | true |