Hi @aish_TF,

To clarify how Ataccama handles contact records with the same party instance record ID:

• Loading: Ataccama loads all contact records, even with identical party instance record IDs. This ID is simply a foreign key linking contacts to parties.
• Matching: Contact matching relies on master_party_id, contact_type, and contact_value. Identical values across these attributes trigger a match and assign the same master ID.
• Merging: Ataccama merges matched records, selecting attribute values based on your configured rules.
• Party-Contact Dependency: Contacts depend on their parent Party record. The party_master_id (generated during Party mastering) is copied to the Contact entity. This ensures that contact matching/merging occurs after the parent Party is mastered.

I hope this helps! Feel free to reach out if you have any more questions.

Hi @ivysakh 

I do have another question that concerns the significance of source_id and party_source_id fields as defined in load for contact. From what I have understood, party_source_id is supposed to be a unique identifier of each record in the party entity. Tnis acts as a foreging key for party_has_contact relationship. The source_id seems like a unique identifier for each of the contact_values. In the source_id, we prefix a value generally, can you explain the purpose of this. 

TIA
Aishwarya

Hi @aish_TF ,

You're right, the Source ID is the primary key (PK) in an entity's instance table. It can either come directly from the source system or be generated within MDM.

The logic for assigning Source IDs is defined in the corresponding load operation. A common practice is to include the source name in the ID (e.g., "CRM_123") to ensure uniqueness across all sources.

To give you a more tailored explanation, could you share how Source IDs are currently assigned for your contact entity? I can then provide specific guidance in that context.

Hi @ivysakh 

Here is an example on how source_id are defined in contact entity  for two different source systems in context of my project.
For one of the source systems, it could be  “OFFICE_PHONE~^~phone_id” and the for other it could be “PERSONAL_PHONE~^~phone_num”.
Where phone_id column is the id of each phone number and phone_num column is the phone number value in the source. This was previously configured, not by me and I am not sure if there is a reason for a prefix which is the same as contact_type followed by a value which is the same as contact_value for contact entity in case of second source mentioned in this example. Please let me know if I should check something else as well.

Aishwarya

Hi @aish_TF .

You have two source systems with different Source ID formats for the contact entity:

• Source System 1: "OFFICE_PHONE~^~phone_id"
• Source System 2: "PERSONAL_PHONE~^~phone_num"

Potential Improvements and Considerations:

• Uniqueness: Since the primary goal of a Source ID is to uniquely identify each record from a source system;
  • System 1: Using phone_id likely ensures uniqueness, as it's a primary key in the source.
  • System 2: Using phone_num might be unique if phone numbers are unique within that source system. However, this could be problematic if the same phone number can be associated with multiple contacts (e.g., a shared business line). Including contact_type in the Source ID will avoid this duplicate issue to some level. As long as the combination of  contact_type and phone_num is unique, you shouldn’t face any issues.

Thank you @ivysakh 

But there is no reason to make source_id have contact_type value for internal usage right? Like for creating a set values from contact entity(using ^~ as seprator) to be utilised in party_match component? 

As for uniqueness, I also had same doubt regarding the second system. As I mentioned this configuration was not done by me. It was done by someone before me.
I did check the records for uniqueness and they are unique in the current configuration for System 2. I do have my inhibitions to continue with the same config though.