---
title: "Questions Around Kenect Specific Contact Data"
canonical: "https://resourcecenter.kenect.com/space/Messaging/41059123/Questions%20Around%20Kenect%20Specific%20Contact%20Data"
format: markdown
---
### In short, it's likely because that contact's phone number was changed. At its core, Kenect is still an SMS platform and therefore shares SMS's issues and quirks. Combined with the unique features of our platform, this creates some odd behavior and confusing display issues. Let's dissect them!

- [How this happens?](#How?)
- [So what if this happens?](#So?)

 

 

***The golden rule to remember here is that Contacts and Conversations are separate entities in Kenect*****. **Updating one of these things does not guarantee that the other will be updated. Remember, the '*Inbox*' is just a portal used to look at Conversations. However, especially with the introduction of the Contact Drawer, there are little windows that look into Contact data that is ultimately stored separately from the information we have about individual Conversations.

 

 

## **How?**

There are a couple scenarios that are known to create this issue.

 

***Scenario #1***:

The end-user contacts our client with phone number A, and is stored as a Contact. Then, that same end-user contacts again with phone number B, and our client simply updates the ***existing contact**** *with the new phone number.

- This creates a "*split*" in the Inbox, and will appear as two different conversations.
- When phone number B is assigned to the Contact, phone number A is deleted.
- However, the old conversation still exists in Kenect and it still remembers phone number A.
- Nonetheless, the old conversation and the new conversation are both linked to the **same contact**.

 

***Scenario #2***:

Our client messages an end-user using a number provided outside of Kenect, but as it turns out: it was the wrong number. They save this wrong number as a Contact. Later, when they find that the message failed, they update the Contact with the CORRECT number and message again. Since the first message failed, the Conversation was not created in our system (even though it is technically still visible in the Inbox). Here is an example of this scenario:

![image-20240429-151030.png](media://af95e469-f0d3-42b2-973e-4b97b89b2093)

  

This is where the limitations of SMS as a protocol come into play. Here's an example I created using my own Android phone:

1. I create a contact called 'Kenect Test' with the number +18002223456, then messaged that Contact.
    
2. I edit the contact and add a new mobile number (+18002224567).
    
3. I send the new number (existing contact) a text message, and it splits into a new conversation in my messages.
    

Under normal circumstances, Kenect is smart enough to merge these Conversations into one. It is only during one of the two scenarios explained above that this issue will occur.

 

 

## **So?**

Well, it's because of this part I mentioned earlier: "*there are little windows [in the Inbox] that look into Contact data*".

 

Clients who find themselves in one of the two scenarios above might click on the former conversation and feel like the information in the ***Contact Drawer**** *is tied to the Conversation, not just the Contact. Then, they try updating that info from the Contact Drawer, not realizing that it's updating the correct/current Contact.

 

For example, if they were to change the name there to "*DO NOT USE THIS #", *it will update the name for the correct/current Conversation as well. See the issue?

 

This is also visible in the search bar at the top:

![image-20240429-151201.png](media://d3c20a2f-a7be-473a-b1d7-1e4d57d2a679)

  

This is because the results here show the Contact's ***current phone number***, but each individual ***Conversation*** is its own entry on the suggested-results list. [*This was raised as a feature request on 10-3-2022 and may no longer be an issue.*]

###  

 

Please let us know if you have any questions regarding this process/the article.