Handoff scenarios

Ada supports multiple configurations for escalating email conversations to human agents. Depending on your agent platform, channel setup (e.g., Email, Web Chat, or both), and desired escalatory experience for human agents and end users, you can choose to create new tickets or update existing ones, and determine how human agents should respond.

Common scenarios

This section covers some of the most typical multi-channel scenarios you might encounter. While many involve deciding whether to create a new ticket or case or update an existing one, others—such as using Email as an extension of Chat—focus on address and threading rules, and sometimes involve replying to existing tickets in your agent platform (e.g., Zendesk, Salesforce). Additional scenarios may apply depending on your specific implementation.

Scenario 1: Email API–only implementation (no Direct Email)

This flow explains how to update existing tickets instead of creating new ones, because every conversation in this setup starts from an existing ticket. It applies to:

  • Email-only implementations
  • Omni-channel implementations (when using the Email API for the Email channel)

To set this up, follow these steps:

  1. Create a handoff flow in Ada with a rule that makes it trigger only for the Email channel.

  2. Pass the originating ticket ID into Ada.

    In the webhook that passes inquiries to Ada via Email API, include the ticket_ID in the Email API metadata. For example:

    {
    "name": "My Test"
    "subject": "CC Test",
    "reply_to": "john.smith@example.test",
    "text": "This is a test ticket body.",
    "reply_as": "help@example.test",
    "cc": ["alice@ventura-bank.test", "tim@ventura-bank.test"],
    "metadata" : {
    "ticket_id": "1001"
    }
    }

    The variable name from the Email API metadata is saved in Ada with an Ada prefix to indicate its source. In the above example, the ticket_id is stored as ada_email_webform_ticket_id.

  3. Follow the platform-specific instructions to configure how Ada updates tickets.

    Add an HTTP Request block to your handoff and call Zendesk’s bulk update endpoint:

    1. In the HTTP Request block’s URL field, append the Ada-prefixed variable to the end of the endpoint URL.

    2. Under Headers, add an Authorization token.

    3. Under Body Content, link each relevant Zendesk field you want to update to its corresponding Ada variable.

    Add a Salesforce block to your handoff.

    1. In the Salesforce block, set the Select Action field to Update Case.

    2. Link each relevant Salesforce field you want to update to its corresponding Ada variable.

    If the platform provides an API endpoint for updating tickets, use an HTTP Request block together with the Ada-prefixed variable in the update request.

FAQs

When an end user emails Ada directly, there’s no ticket/case yet in Zendesk or Salesforce. The conversation lives in Ada until a handoff is initiated. At escalation, Ada creates a new ticket/case (which receives a ticket ID). This ticket ID can be passed back to Ada only if the handoff block is configured to save it.

  • Zendesk: No. Updating a ticket via an HTTP request does not support shared email address/thread behavior. That behavior is supported only by the Zendesk Support block.
  • Salesforce: No. Replies to updated cases will start a new email thread, since human agents must use a different email address than the AI Agent.

If human agents reply to a Zendesk ticket not created via the Zendesk Support block, they must use a different support email than the AI Agent’s configured email. This applies to:

Scenario 2: Create new tickets with Direct Email, update existing ones with Email API

If you are using both Email API and Direct Email, Ada can differentiate between the two and route handoffs accordingly. In this scenario, Email API conversations update existing tickets, while Direct Email escalations create new tickets. The handoff should be gated for the Email channel.

It applies to:

  • Email-only implementations
  • Omni-channel implementations

To set this up, follow one of these handoff flows:

  • Single handoff flow gated for the Email channel, with conditionals: If a conversation contains a specific variable, or it originates from:
    • Direct Email, then configure the handoff block to create a new ticket or case.
    • A Webform, then configure the handoff block to update an existing ticket or case.
  • Two handoff flows, each gated by origin (Direct Email or Webform) or metadata (containing a specific variable):
    • One for updating existing tickets
    • One for creating new tickets

Here’s what this looks like in practice in different platforms:

Notes:

  • Zendesk Support block allows human agents to reply to Email handoffs using the same support address configured with the Email AI Agent; these replies will stay in the same thread.
  • If using the Zendesk Ticketing block for asynchronous messaging handoffs, human agents must reply using a different support email address than is used for the Email channel.
  • Tickets updated via the HTTP Request block must be replied to from a different support address than the Email AI Agent. This can be the same address used for Chat handoffs.
  • Use the Salesforce block in your handoff
    • To create a new case, in the Salesforce block, set the Select Action field to Create Case.
    • To update an existing case, set the Select Action field to Update Case.

Regardless of the setting, human agents must reply from a different support email address than the Email AI Agent. Replies will go to end users in a new email thread.

  • If the platform has an API endpoint for ticket creation, to create a ticket, use the Email or HTTP Request block.
  • If the platform has an API endpoint for ticket updates, to update a ticket, use an HTTP Request block.

Scenario 3: Email as an extension of Web Chat

In omni-channel configurations, Email is sometimes used as a fallback or follow-up method for Chat handoffs. In these cases, human agents may be replying to existing tickets in your agent platform (e.g., Zendesk, Salesforce) over email. For any implementation that includes Ada’s Email channel, it’s important to plan which email addresses your human agent teams and your Email AI Agent will use to ensure correct threading behavior and avoid unexpected AI Agent re-entry.

For more details, see this decision table.

  • Human agents can only use the same support email address configured for the Email AI Agent (in BYOD settings) if they are replying to tickets created via the Zendesk Support block. These replies will stay in the same thread.
  • Human agents replying to tickets created by any other ticketing block Zendesk Ticketing, Salesforce, or Email or created directly by human agents in Zendesk/Salesforce must use a different support email address than the one used by the Email AI Agent.
    Examples include:
    • Proactively created tickets in Zendesk/Salesforce
    • Chat asynchronous handoffs responded to via email during live agent offline hours

Have at least two separate support email addresses:

  • One for the Email AI Agent (and human agents replying to email handoff tickets created by the Zendesk Support block)
  • One for human agents replying to all other tickets (e.g., those created via Zendesk Ticketing, Salesforce Case, or manually by agents)

You can use multiple support addresses for human agent teams, as long as none of them are the same as the address used by the Email AI Agent.

If a human agent replies from the same address used by the AI Agent, but the ticket was not created by the Zendesk Support block, Ada will receive all end user replies to those human agent messages. In this case, the AI Agent may re-enter the conversation with no context, leading to a broken experience and loss of context for the end user.

Combining handoff blocks across channels

Depending on whether you want email or chat escalations (or both), you can mix and match handoff blocks as needed.

If using Zendesk Support for both Chat and Email, create two separate handoff flows, gated by channel.

Best practices

Configuring handoff blocks

  • Use system variables (purple) in all handoff blocks
  • Common variables include:
    • email
    • name, first_name, last_name (generated from email)
    • ada_email_subject (from email subject line)
    • email_attachments: Required only for the Zendesk Ticketing, Salesforce, and Email blocks

Examples

Here are some example configurations for common email handoff scenarios, showing how to apply best practices in different situations.

In this example, CC_list is a custom Zendesk field to store CC’d participant email addresses.

Enable the Track as handoff setting to ensure proper reporting.

Handling original tickets from Email API

Here’s a common workflow for handling original tickets from the Email API:

  1. Customer fills out Webform that causes a ticket to be created
  2. Ticket automation calls Ada API
  3. Conversation is handed off
  4. Ada either:
    • Updates the ticket (if still open)
    • Creates a new one (if closed)
  5. Optional: Automation closes tickets after five days

Additional best practices

  • Create a dedicated handoff flow for email, gated by channel = Email
  • Use conditionals and Ada variables to decide when to create vs. update a ticket (Zendesk and Salesforce only)
  • Choice of handoff block depends on whether agents need to:
  • Zendesk has a free app that lets agents switch the from email address in tickets