How to use Multi-Solution Conversations (MSC) | Developer Documentation

Confirm the arrangement before treating several tools as one conversation

When several teams or systems are involved, first confirm which connections and tools are supported for the number. Meta's Multi-Solution Conversations reference does not establish that ChatArchitect provides that arrangement, mirrors all messages between tools or exposes its solution fields in customer API requests.

Define the expected work in each tool

For each proposed or existing tool, record the business number, responsible administrator, sending workflow, intended incoming-message destination and automation that may respond. Use the routing record to keep several numbers separate. If several tools appear to use the same number, ask the setup coordinator or support to confirm the supported arrangement before extending it.

Agree which team should answer a new inquiry, whether another tool needs to see that answer, and who resolves duplicate or missing responses. Visibility in one CRM does not prove that another CRM receives the same history or result.

Compare one controlled example

1. Choose an authorized test contact and a time when the responsible people can observe the tools. Record the expected destination and avoid overlapping automated replies.
2. Record one incoming message and where it appears. Separately record one permitted reply from the intended tool and the result available there.
3. Check any other tool only for the visibility that was agreed. Mark an unavailable record as unverified; do not interpret its absence as proof that the message was not sent.
4. If replies repeat or come from an unexpected system, use the unexpected-reply investigation to identify the sending workflow before changing it.

Separate routing, delivery and charges

The receiver guide explains how to check incoming chats and outgoing results separately. Use API onboarding and the current API Quick Start for a custom ChatArchitect implementation; do not add an undocumented solution identifier to a send request.

For charges, use the pricing guide and the actual customer agreement. An imported MSC billing example does not tell you whether two tool records represent two billable events.

Escalate the observed difference

Give the responsible team the number, tool names, time, intended action and available request or message references. State whether the difference concerns sending, the customer's received message, a result callback or CRM visibility. Ask for the supported routing and history scope where it is unknown.

Historical Meta reference illustrations

These original illustrations show the separate Meta provider workflow retained from the former reference. They do not establish current screens, eligibility, a ChatArchitect customer control or supported parallel connections. Use the confirmed customer instructions above for your setup.