Contact messages endpoint

[M-Shorouk]

Is your feature request related to a problem? Please describe.

As an Airy Agent, i need to be able to see a section on the conversation level that reflects this contact's last tracked activities. E.g: (Purchased X)

Describe the solution you'd like

See discussion below.

POST /contacts.recent-messages

Sample request

{
    "contact_id": "id of the contact to query",
    "filter_sources": ["salesforce_history"] // optional inclusive OR filter of sources to show
    "cursors": { // optional
        "conversation-id": "some cursor" // allows scrolling within the messages of a conversation
     }
}

Sample response

{
    "conversation-id-1": {
        "source": "salesforce_history",
        // metadata?
        "data": [], // Same as for paginated message list https://airy.co/docs/core/api/endpoints/messages#list
        "pagination_data": {}
    },
    "conversation-id-2": {} // ...
}

[chrismatix]

@M-Shorouk Since #2753 is blocked by this I think it makes sense to start here:

I want to better understand the nature of these contact events. What type of systems generates them and can we somehow accommodate them in our concept of a conversation?

Context: In a previous discussion I outlined that introducing events might mean that we would end up duplicating our entire conversational infrastructure. Therefore it seems economical to instead expand the definition of a conversation to purchase histories (or any type of customer event).

What do you think?

[AitorAlgorta]

I think systems such Salesforce will create events that we want to add to conversations.

The idea is that those events are also part of the conversation, so we can see the events inside the conversation view, but also be able to list them separately, without other messages.

[chrismatix]

@AitorAlgorta understood. Then this is the same topic and I would still argue for treating these events as messages where the source is either salesforce or something like salesforce_purchases.

If we want to exclude messages from other sources in this webhook we could add a filter to the webhook configuration.

Alternative

We treat these events as a metadata JSON blob that we attach to the contact without any opinion on the structure. This is closer to what is asked here but also makes integrating this data with conversations much harder in the future.

[AitorAlgorta]

how easy is to add those events to already existing conversations? doesn't look really easy. I think the second option makes more sense

[chrismatix]

@AitorAlgorta We already have a salesforce connector that could take care of that. With events, the onus is shifted on the customer to maintain events.

Merging communication data with other customer events in a single abstraction of conversations is part of our core value proposition. Therefore introducing "contact events" that somehow aren't messages seems counterproductive

[chrismatix]

Events as messages proposal

Given the above debate these events would be consumed as regular messages from a source such as salesforce purchase histories. For the sake of the argument, we could say that they are part of a new source salesforce_purchases.

As an Airy Agent, I need to be able to see a section on the conversation level that reflects this contact's last tracked activities. E.g: (Purchased X)

This from the original requirements then becomes: As an Airy Agent I want to be able to see recent activities of the agent in other conversations.

We can facilitate this by introducing a new conversation view that aggregates all the recent messages for each conversation. The API for this could look like so:

POST /contacts.recent-messages

Sample request

{
    "filter_sources": ["salesforce_history"] // optional inclusive OR filter of sources to show
    "cursors": { // optional
        "conversation-id": "some cursor" // allows scrolling within the messages of a conversation
     }
}

Sample response

{
    "conversation-id-1": {
        "source": "salesforce_history",
        // metadata?
        "data": [], // Same as for paginated message list https://airy.co/docs/core/api/endpoints/messages#list
        "pagination_data": {}
    },
    "conversation-id-2": {} // ...
}

On to #2753:

Here we would then expand the webhook and allow users to add some context, one of which would be recent messages. This again could be filtered by source.

This endpoint could also be used in the future to build an aggregated view of a contact conversation (working title) where one can see the conversations with an agent across all sources and conversations.

This approach has the following advantages:

• Avoids introducing data structures that are as of yet poorly understood
• Composes existing message concept into a more powerful representation
• Follows our conception of universal conversations and allows us to own the purchase history data

Drawbacks:

• Aggregated conversation views are expensive in terms of storage
• Therefore this will only make sense for customers that correlate users across instances

Please let me know what you think @AitorAlgorta and @M-Shorouk

[M-Shorouk]

@chrismatix thanks for your Proposal.

it is actually how we scoped this contacts.events; syncing contact.events from third-party e.g. Salesforce and rendering these event.triggers to the relative contact.conversation.

[chrismatix]

@M-Shorouk I am not sure I understand: Does this mean the proposal works for you?

[M-Shorouk]

@chrismatix Yes the proposal works 🙌🏻.. what do you think @AitorAlgorta ?

[AitorAlgorta]

Ingestion as messages is good and makes sense.
We should model how the events look like and how values can be mapped
eg. some events might include email addresses as personal information or customer ids
the API is a bit too cryptic in my opinion and jumps two steps ahead

[AitorAlgorta]

"conversation“ makes sense defined as aggregation including personalized information
then can be attributed to the same contact

[AitorAlgorta]

the question is if we can do aggregations as well for events that don't hold a personal identifier
or disregard it as the case may be to return all purchases
eg. in the API messages.list for event type instead of conversation id
that would be more logical in my opinion

[chrismatix]

Thank you, @AitorAlgorta. As far as I understand these are advanced features of both the yet-to-be-built source implementation underlying these purchases (salesforce?) and of the messaging list in general.