We are working on a new Inbound message flow for FB Messenger DMs. Our objective is to associate the interaction with an existing (or newly created) external contact in a particular External Organization, and have the contact represented to the agent without the agent having to confirm the contact.
We are using API /api/v2/externalcontacts/organizations/{externalOrganizationId}/contacts to search for the External Contact in the Organization based on the FB scopedId.
If an existing contact is not found, we are using API /api/v2/externalcontacts/contacts to create the contact in the particular Organisation including the FB scopedId and displayName as Messenger identifiers.
We are then using API /api/v2/externalcontacts/conversations/{conversationId} to associate the contact with the interaction.
All of this is working but when the interaction is presented to the agent, the agent is being asked to confirm the contact and is also given the option of substituting several other contacts from other Organizations with similar names to the FB display name. This seems odd since the contact has been positively identified and associated.
Is there a way of ‘confirming’ the contact in the flow so the agent does not get the option to confirm or substitute ?
Hi @MurrayS
Your contacts should have e164 phone numbers, so that is one thing to check. Also, this thread covers another possible scenario, that the supposedly new contact has actually been created previously with a test call, and so the agent is being prompted to merge the matching contacts together.
The interactions are incoming from FB Messenger and there is no phone number. The inputs from FB are passed into variables Message.Message.senderAddressInfo (which contains the FB ID) and Message.Message.senderAddressInfo.name (which contains the FB display name). We are mapping them to scopedId and displayName in the external contact.
The correct contact is being associated, we can see it in the result returned by Get Conversation, and all of the test interactions are being correctly assigned to the contact, we can see them all listed under the contact.
The problem is the contact is being presented to the agent with a 'Confirm Contact' button, and several alternative contacts (from all External Organizations) are also being presented based on some sort of fuzzy logic match on the FB displayName. This is confusing the agents.
We have confirmed there is only one contact with the correct FB scopedId.
Thanks for clarifying, I missed that. Your approach sounds correct. I'm curious where you are getting the communicationId that you use in the call to PUT /api/v2/externalcontacts/conversations/{conversationId}? For messaging conversations, typically you would call GET /api/v2/conversations/messages/{conversationId}, then find the participant with purpose "customer", then get the messageId of the first message within that participant. Assuming the customer was the first participant, it would look like participant[0].messages[0].messageId
We are using the same method to get the communicationId as we use for voice calls, i.e. we run GET /api/v2/analytics/conversations/{conversationId}/details and pick out the peerId for the 2nd participant. I think this was on the advice of Genesys a couple of years ago. The same method seems to work for Messages.
We have tried your suggested method but could not get the Associate API to work for any of the MessageIds returned from GET /api/v2/conversations/messages/{conversationId}. The Associate API returns a 202 Accepted but the external contact isn't actually updated from the ephemeral Id generated automatically.
We can see the same "peer" (Id) in GET /api/v2/conversations/messages/{conversationId} as well, so it's probably a better option than the analytics API.
We would be interested to know why using the MessageId doesn't seem to work.
GET /api/v2/analytics/conversations/{conversationId}/details is also a viable resource for this situation. However if you're using that, you would find the sessionId in the customer's participant with the mediaType=message, and use that as the communicationId. This id should have the same value as the id's from the messages array in the within the participant as outlined in my last post. Source: