For correct operation, you must use the dedicated Conversations service for Flex, “Flex Chat Service”. Furthermore, “Flex Chat Service” must be configured as the default Conversations service.
When you create an interaction, a task and a reservation will be created according to your specified Routing attributes. You may update the task attributes but deleting or canceling a task are not supported. You must use the Interactions Channels subresource. For more information, please refer to the Interaction Channels documentation.
Refrain from using PII (personally identifiable information) such as number or email address as the identity for custom chat identities.
For channels that are NOT long-lived, we recommend that you use the built-in state timers on Conversations to close the conversation after a certain time of inactivity. This prevents orphaned conversations. Please refer to the Conversations states and timers documentation for more information.
You must ensure that you handle certain terminal TaskRouter events according to your application's needs. For example, if a workflow timeout occurs, you may want to automate a message or re-invite the agent or the workflow to a different workflow using the Invites Subresource. Please ensure the following events are handled as needed by your application:
Refer to the TaskRouter event documentation for more information.
To read Conversation attributes in a Studio Flow, you must use the attributes on the Conversation rather than the message. The Incoming Conversation trigger supports JSON payloads for Conversations Channel attributes but not the message one. You can read the JSON value from the trigger's ChannelAttributes attribute.
If you are unsure why things are not working, consider checking the Twilio Console debugger. Flex Conversations logs warnings for when Flex fails to create interaction channels.
In Flex Conversations, all agents have a Chat identity. Flex does not support adding Flex agents directly to an ongoing interaction channel or conversation. To add an agent to a conversation, you must have the interaction channel SID and use the Invites endpoint. See Invites Subresource documentation for more information.
Since Interaction Channel creation is asynchronous and the status reason does not indicate a failed status, you can register to receive task.canceled events to determine if an interaction channel creation failed.
An SMS or WhatsApp participant is identified by the number/proxy-number pair in the messaging bindings attributes. This number pair binding may only exist in one non-closed (either "active" or "inactive") conversation. If you attempt to add the same participant to another conversation, the request will fail.
Therefore, if you’re creating an outbound interaction and specifying the participant, ensure that the participant is not in a non-closed conversation already. You can use the Participant Conversation Resource to check for non-closed conversations.
Another approach is to create the conversation first and then the interaction. This way when you add the participant to the new conversation, the add will fail and return the conversation SID of the conversation that the participant is already in.
If your use case requires that you inspect and/or modify messages sent or received to a conversation, consider using the pre-event webhooks available in the Conversations API. See the Per-Service Webhook Resource for more information.