Find contact data using GraphQL
Unlike our Rest API, which provides contact indicators, our GraphQL API provides conversation indicators. However, you may wish to go down to a per-contact granularity also for GraphQL indicators.
Contact vs conversation definition
- A contact is an exchange between a visitor and an operator (agent, expert or bot). It can be a chat, call or video contact.
- A conversation can include several contacts, especially if they have been transferred or snoozed.
A conversation can therefore include several contacts when it is ended.
Fields to be used
The fields/properties mentioned are available in the Conversation
type/object. This Conversation
object is available through (depending on your needs) two queries:
closedConversations
: which returns a paginated list ofConversation
objects that are closed only.conversation
: which returns aConversation
object based on its id (in uuid format).
As a reminder, GraphQL doesn't explicitly expose the notion of "contact", but it's entirely possible to reconstruct this notion by exploring the lifecycle of the conversation through the various distribution events (routingEvents
) or events occurring during the conversation via messages of type SystemMessage
in the messages property (theConversationPushedSystemAttachment
attachment that systematically marks the start of a new contact).
Here are all the fields/properties of the Conversation object you'll need to make your request:
Field | Comments |
---|---|
DATE/TIME (opening) | The goal is to retrieve the start date of each contact for which a |
DATE/TIME (close) | See point above. If you need to retrieve the conversation's closing date, it is available in the |
ID_ CONTACT (unique) | There's no such thing as a contact id, but it's possible to build one by concatenating various pieces of information, such as the conversation id and the date ( |
SITE_ID | This is the |
CHANNEL (chat/wa/ etc.) | This is the |
ID_ OPERATOR | It is possible to retrieve the information (id, name, email, etc.) of the user who has processed a contact. This information can be accessed in the |
ID_ CONVERSATION | This information is available in the |
ROUTING_RULES | The goal is to determine which group(s) of respondents actually handled the contact. This information is available in the Chronologically, a distribution event necessarily occurs before one or more For example, a conversation with two contacts handled by the same operator. We can clearly see two 11:00:00 routingEvent (routingRule+routingGroup) 11:00:01 ConversationPushedSystemAttachment 11:00:05 ConversationSnoozedSystemAttachment — conversation returns 5 minutes after snooze 11:05:05 ConversationPushedSystemAttachment … … 11:10:00 ConversationClosedSystemAttachment
|
CONTACT_ STATUS (answered, unanswered, transferred, snoozed...) | This involves retrieving events that have occurred during the conversation. iAdvize exposes all these events in the Here is an example of some of the events you may encounter:
|
ENDING_ CONTACT (reason) | The need is to determine whether the contacts have resulted in : - a closing - a transfer - a snooze - ...
This information can be retrieved via the |
Find conversation contacts through SystemMessage
Example of a query
In the following example, we retrieve the distribution information as well as the events in the conversation's lifecycle (marking, in particular, the beginning and end of contacts).
We therefore find 3 contacts symbolized by the presence of 3 attachments of type: ConversationPushedSystemAttachment
.
As the conversation has been transferred to distribution rules, we also find 3 distribution events in the routingEvents
property.
Query
Response / result
Last updated