Multiple participant Conversations

Your Email AI Agent can reply within threads that include multiple participants, supporting up to 25 recipients in the To and CC fields (not including the original sender).

• If a message includes more than 25 recipients, the Agent will prioritize those listed in the To field.
• Any recipients beyond the 25th—starting with those in the CC field—will be excluded from the Agent’s reply.
• As long as the total number of recipients remains within the limit, the Agent will continue to reply to all participants in the thread.

When handing off these conversations to your support platform, it’s important to pass the correct participant data—like the most recent sender and the full list of current recipients—so that human agents can respond with the full context.

This topic explains the system variables that help manage multi-participant email threads. For configuration steps and setup guidance, see Managing CCs in support tickets.

System variables

When the AI Agent detects a multiple participant Conversation, it sets the following system variables. AI Managers can use these system variables for their configurations across the dashboard. For example, AI Managers can use these variables to set rules on sensitive Knowledge articles or Processes that should not be used by the AI Agent when there are more than one end user in the Conversation.

has_multiple_participants

A boolean value that is:

• TRUE if the message includes more than one participant
• FALSE if only a single sender is involved

Best practice

Use this variable to gate sensitive workflows or Knowledge that should only run in one-on-one conversations.

For example:

Where has_multiple_participants is NOT TRUE

or

Where has_multiple_participants is FALSE

email_from_address

The email address of the person who sent the most recent message.

• May be the original sender or a CC’d participant
• Should be passed as the requester in your ticketing system

email_latest_CC_list

A list of the To and CC recipients from the most recent message in the thread.

• This list reflects only the latest message, not the full history of participants
• If recipients are added or removed over time, the content of this variable includes only the email addresses of the most recent recipients

Best practices

• Only the Zendesk Support block passes the latest list of participants automatically into the ticket.
• If you’re using the Zendesk Ticketing block, Salesforce Case block, or Email App block, you’ll need to configure the email_latest_CC_list variable manually in your handoff block.
  • This involves creating a custom field in your agent platform to receive and store the list of email addresses.
    • In Salesforce, you’ll likely also need to create an automation to dynamically populate the CC field in the human agent’s reply using that field.

Restricting sensitive flows

When your AI Agent engages in conversations with multiple participants, anything it says or collects is visible to everyone in the thread.

If your Agent asks for private or sensitive details—like account numbers, refund reasons, or authentication—we recommend restricting those flows to single-participant conversations by gating the applicable Actions, Processes, or Knowledge so they are only available in single-participant conversations.

Use has_multiple_participants to gate these flows. For example:

Where has_multiple_participants is NOT TRUE

or

Where has_multiple_participants is FALSE

This ensures sensitive actions are only triggered when there’s a single participant on the thread.

Metadata in multiple participant Conversations

In Conversations involving multiple participants (via the To or CC fields), your AI Agent may receive messages from different senders within the same thread. However, any metadata shared with the Agent—such as global variables, system variables, or data passed through the API—is always tied to the original sender who initiated the conversation.

This means:

• Even if another participant replies later in the thread, metadata does not shift to that person.
• Your Agent continues to reference the original end user’s profile and metadata throughout the Conversation.

Why this matters:

• Consistent context: Your Agent maintains a clear association with the original end user, ensuring metadata like preferences, account details, or escalation logic isn’t mistakenly linked to someone else in the thread.
• Predictable logic: You can safely design rules, flows, and Handoff behaviours based on a single end-user identity, even when others are CC’d or join the Conversation later.

If your use case involves personalized experiences, sensitive workflows, or profile-based decisions, this behaviour prevents the Agent from switching context mid-thread.

Configuring multiple participant Handoffs

To properly escalate multiple participant email threads:

• Set the appropriate requester field (e.g., requester or user email, as applicable) using email_from_address
• Populate the relevant CC or participant list field (as supported by your platform) using email_latest_CC_list

Platform notes

• Zendesk Support block: Automatically handles CCs and participant lists. No setup required.
• Zendesk Ticketing & Salesforce: These platforms do not automatically process CCs from incoming emails. To ensure multi-participant visibility and agent replies:
  • Create a custom field to pass the list of additional participants into the ticket.
  • Map system variables (email_from_address, email_latest_CC_list) into those fields in the appropriate handoff block.
• Salesforce:
  • Use the email_from_address variable to populate the “Email address” field in the Salesforce case block.
  • Set up an automation to populate the “To Address” and the “CC Address” fields when the human agent is replying in the case.
• Zendesk Ticketing:
  • Use the email_from_address variable to populate the “Chatter’s email” field in the Zendesk Ticketing block.
  • When replying to Zendesk tickets created by the Zendesk Ticketing ticketing block, human agents must manually copy paste the all participant emails from the custom field into the CC field of the ticket reply.
• Other platforms / Email App block:
  • Use the email_from_address variable to populate the “Reply-To Email” address for the Email app block, and email_latest_CC_list to populate the “CC Email(s)” address.
  • If the agent platform supports standard email headers, Ada’s Email App block will automatically pass the Reply-To and CC headers. No custom fields or automation are needed—CCs will be preserved in the outgoing message and replies will include all participants.

Best practices

• Always pass email_from_address to represent the requester
• Include email_latest_CC_list if your platform supports CCs
• Use has_multiple_participants to prevent sensitive flows
• Avoid using sensitive content (like account data, refunds, or personal questions) in threads with multiple participants

Managing CCs in support tickets

When a Conversation with multiple participants is escalated to a human agent via an Email Handoff, it’s important to ensure that all current recipients—listed in the latest To and CC fields—are included in both the support ticket and any related replies.

Automatic CC handling

If you’re using the Zendesk Support block, Ada automatically saves and passes the full list of recipients from the latest message into the Zendesk ticket. Human agent replies are sent to all participants in the same thread.

This is the only handoff block that provides full multi-participant support out of the box.

Manual CC handling

For other handoff blocks (like Zendesk Ticketing, Salesforce Case, or Email App). Ada does not automatically populate the CC field in your agent platform. To replicate this functionality:

1. Zendesk Ticketing and Salesforce only. Create custom fields.

   You’ll need two fields:

   • One to store the email address of the original sender
   • One to store the email addresses of participants in the latest CC list

   These can be new custom fields or existing fields already available in your ticketing platform.

2. Pass system variables into the appropriate handoff block.

   Use the following system variables to populate the custom fields:

   Variable	Description
   email_from_address	Email address of the latest sender (used to populate the requester field)
   email_latest_CC_list	List of To and CC recipients from the most recent message
   has_multiple_participants	Boolean indicating if there is more than one participant

   Salesforce

   • Map @email_from_address to the existing “Email Address” field.
   • Map @email_latest_CC_list to the field representing the CC participant list on the case (e.g., CC List). You may need to create that field in Salesforce if you don’t already have one.

   

   Zendesk Ticketing

   • Map @email_from_address to the “Chatter’s Email” field.
   • Map @email_latest_CC_list to the custom CC list field (e.g., CC_list).

   

   Other platforms / Email App block

   • Map @email_from_address to the Reply-To Email field so that the end user appears as the sender in the ticket.
   • Map @email_latest_CC_list to the CC Email(s) field so that all current To and CC recipients are included in the ticket and automatically receive replies.

   

3. Ensure human agents can reply to all participants.

   Salesforce

   Set up an automation to populate the To and CC fields on the case using the custom fields. This allows agents to reply to all participants without manual copying.

   1. In Salesforce, go to the Object Manager for the Case object.

   2. In the left navigation, select Buttons, Links, and Actions, then click the Email action.

      

   3. In the Email action screen, scroll to the Predefined Field Values section. Next, add two new predefined field mappings—one for the CC Address field and one for the To Address field on the case.

      

      Here’s an example of what those field mappings might look like:

      

   Zendesk Ticketing

   Human agents must manually copy-paste email addresses from the custom field into the CC field of the ticket before replying.

   Other platforms / Email App block

   If the platform respects standard email headers, it will automatically display the sender and CC’d participants in the ticket, and agent replies will include everyone—no mapping or custom fields required. Ada simply passes the data via the outbound email itself.

Summary