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.
Last updated
Was this helpful?
- 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.
closedConversations: which returns a paginated list of Conversation objects that are closed only.
conversation: which returns a Conversation object based on its id (in uuid format).
Here are all the fields/properties of the Conversation object you'll need to make your request:
DATE/TIME (opening)
The goal is to retrieve the start date of each contact for which a ConversationPushedSystemAttachment message occurs systematically.
DATE/TIME (close)
See point above.
If you need to retrieve the conversation's closing date, it is available in the closedAt property.
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 (createdAt) of the ConversationPushedSystemAttachment attachment.
SITE_ID
This is the id property in the conversation's project property.
CHANNEL (chat/wa/ etc.)
This is the channel property
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 toUser property of the system message whose attachment is of type ConversationPushedSystemAttachment.
ID_
CONVERSATION
This information is available in the id property of the Conversation object.
ROUTING_RULES
The goal is to determine which group(s) of respondents actually handled the contact.
This information is available in the routingEvents property, which retrieves the date on which the event occurred (createdAt), as well as details of the rule and targeting group (routingRule and routingGroup) to which the conversation was distributed.
Chronologically, a distribution event necessarily occurs before one or more ConversationPushedSystemAttachment messages (corresponding to the sending of the conversation to the advisor's console or the reception of the conversation by a bot).
For example, a conversation with two contacts handled by the same operator. We can clearly see two ConversationPushedSystemAttachments that can be linked to distribution information (routingRule and routingGroup).
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.
Here is an example of some of the events you may encounter:
ConversationClosedSystemAttachment
TransferredToUserSystemAttachment
TransferredToRoutingRuleSystemAttachment
ConversationSnoozedSystemAttachment
…
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 SystemMessage mentioned above.
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.
The fields/properties mentioned are available in the type/object. This object is available through (depending on your needs) two queries:
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 () or events occurring during the conversation via messages of type in the messages property (theattachment that systematically marks the start of a new contact).
iAdvize exposes all these events in the messages property with the SystemMessage type. It's possible to retrieve the name of this event using the __typename property, as well as information specific to each event, which you can find in our .
