Handing an Agentforce conversation to a human: the Omni-Channel flow, the escalation topic, and the context you can't drop

Every Agentforce demo ends with the agent resolving the case. Every Agentforce deployment lives or dies on the case it can’t. An autonomous service agent that deflects 50% of contacts is a genuinely good agent — which means half the time its most important job is to fail well: recognize it’s out of its depth, stop trying, and get the customer to a human who can finish the job without making them start over. That moment — the handoff — is where customer trust is won or lost, and it’s the part teams consistently under-build because it isn’t the part that demos.

The handoff is also more mechanical than most people expect. It isn’t a vibe the model produces; it’s a specific chain of Salesforce components — a standard escalation topic, an outbound Omni-Channel flow, your existing routing rules — plus a payload of context that has to survive the transfer. Get that chain right and the customer barely notices the seam. Get it wrong and you’ve built the single most infuriating experience in service: a customer who explained their problem to a bot, got told “let me get someone,” and then had to explain it all over again to a human who can see none of it. This is the build that decides whether your agent feels like a front door or a speed bump.

The escalation topic: how the agent decides to give up

An Agentforce Service Agent is organized into topics — scoped subagents — and one of them is the standard Escalation topic. Its job is narrow and critical: recognize when the conversation should leave the agent, and trigger the handoff. Salesforce ships it as a standard topic precisely because every service agent needs it, but shipping it and tuning it are different things.

The default escalation behavior is conservative and generic. In production you customize the escalation topic with instructions and actions so it fires according to your policy, not a vendor default. The triggers worth being explicit about:

• Explicit request. The customer types or says “I want to talk to a person.” This one is easy and non-negotiable — never trap a customer who has clearly asked out.
• Repeated failure. The agent has tried and the customer is still stuck. Left implicit, an agent will loop; instruct it to escalate after it has genuinely failed rather than trying a fourth rephrasing.
• Out-of-scope intent. The request falls outside the topics and actions the agent was given. Billing dispute on a support-only agent, a legal question, anything touching a decision the agent isn’t permitted to make.
• Sentiment and risk. An angry customer, a vulnerable one, a threat to churn or to escalate publicly. These are cases where technically resolvable isn’t the same as should be handled by a machine.

The design principle underneath all four: escalation is a human-in-the-loop boundary, and you draw it deliberately before launch, not reactively after a bad transcript. Write the escalation instructions with the same care you’d write the agent’s core job, because a service agent that never escalates is more dangerous than one that escalates too often.

The outbound Omni-Channel flow: the part that’s actually the build

Here’s the thing nobody tells you at the keynote: the escalation topic decides that the conversation should transfer, but it doesn’t do the transfer. The actual routing is handled by an outbound Omni-Channel flow, and that flow is the real engineering in this whole feature.

On enhanced messaging channels, an Agentforce Service Agent transfers a conversation to a destination — a specific rep or, far more commonly, a queue — using an outbound Omni-Channel flow that you build and then wire into the agent’s connection settings. In the Agentforce Service Agent configuration, there’s an Outbound Omni-Channel Flow setting; the flow you select there is what runs when the escalation topic fires.

What that flow has to do is more than “send to queue.” A good escalation flow answers a sequence of questions:

1. Is a human even available? Check whether agents are online and have capacity for the relevant queue. Escalating into an empty queue at 2 a.m. is a worse experience than a bot that honestly says the team is offline.
2. Which human? Route by skill, language, product line, tier, or account value — the flow figures out the best-fit person or queue based on your routing criteria, exactly the way a human-initiated transfer would.
3. What happens if nobody’s there? Define the fallback explicitly: offer a callback, create a case for asynchronous follow-up, capture a message, or state hours. The absence of this branch is the most common escalation bug in production.

The reassuring part is that this flow rides on top of infrastructure you probably already run. Routing goes through Omni-Channel, so your existing queues, skills, capacity model, and presence rules all apply unchanged — you’re not building a parallel routing system for the agent, you’re teaching the agent to hand into the one you have. A rough shape of the flow logic:

Outbound Omni-Channel Flow (triggered by the Escalation topic)
  1. Get escalation inputs
       - intentSummary        (what the customer wants)
       - escalationReason     (why the agent is handing off)
       - recordIds            (case, contact, order in play)
       - sentiment            (from the conversation)
  2. Decide route
       - determine skill/queue from intent + account + language
       - check queue availability & capacity
  3. Branch
       - agents available  -> Route Work to the chosen queue/skill
       - none available    -> offer callback / create case / state hours
  4. Attach context to the routed work item
       - transcript, summary, case, sentiment, record links

Note step 4. Routing the customer to a person is only half the job. The other half is making sure the person arrives holding everything the agent already learned.

The context you can’t drop

The cardinal sin of a bad handoff is amnesia. The customer explained the problem once; a competent transfer means they never explain it again. Concretely, the human who picks up an escalated conversation should receive:

• The full transcript. Everything the customer and the agent said, verbatim, so the rep can see what was already tried.
• A summary. A short synthesis of the intent and the state of play, so the rep doesn’t have to read a 40-turn transcript before saying hello.
• Sentiment. A readout of how the customer is feeling, so the rep opens with the right tone instead of walking into an ambush.
• The case and record IDs. Any case the agent created during the conversation, plus the contact, order, or asset it was working with — so the rep lands on the right records, not a blank screen.

This is why the escalation action’s inputs matter as much as its routing. A well-designed escalation action carries the intent summary, the trigger reason, and the relevant record IDs as explicit inputs — they’re not incidental metadata, they’re the payload that makes the handoff seamless. Treat them as required:

{
  "action": "Escalate to Human Agent",
  "inputs": {
    "intentSummary": "Customer wants to change the ship-to address on order 1042, already dispatched.",
    "escalationReason": "Address change post-dispatch requires warehouse override — outside agent scope.",
    "sentiment": "Frustrated — second contact about this order.",
    "recordIds": {
      "caseId": "500XXXXXXXXXXXXXXX",
      "contactId": "003XXXXXXXXXXXXXXX",
      "orderId": "801XXXXXXXXXXXXXXX"
    }
  }
}

When this payload rides along with the routed work item, the rep who accepts it sees the full transcript, the summary, and the case that was opened mid-conversation — and the customer experiences a genuine handoff, not a restart. When it doesn’t, you’ve built the two-tiered experience regulators and customers both hate: talk to the bot, then wait again, then repeat yourself.

Enhanced messaging, voice, and the legacy trap

Three channel realities shape how you build this.

Enhanced messaging is the assumption. The outbound Omni-Channel flow pattern is built for enhanced messaging channels — Messaging for In-App and Web and the enhanced channels that share its data model. If you’re on an older messaging stack, confirm the channel supports the outbound flow before you design around it; the routing primitives differ.

Voice changes the choreography, not the principle. With Agentforce Voice, the same logic applies but the handoff is a live phone transfer. When the agent hits a guardrail, a low-confidence intent, or an angry caller, it transfers through Omni-Channel with the transcript, the context, and the sentiment attached — and the rep who picks up sees the full transcript, a summary, and any case created during the call. The customer-experience stakes are higher on voice because the wait is audible, so the “is anyone available” branch matters even more.

Don’t assume your Einstein Bots handoff carries over. If you’re migrating from Einstein Bots, the escalation you built there — often a direct Live Agent transfer or a bot-to-queue action — is not the Agentforce mechanism. Agentforce routes through the outbound Omni-Channel flow, and the transfer logic is a rebuild, not a port. Budget for it; it’s one of the pieces of a bot migration that looks done and isn’t.

Measure the handoff, not just the deflection

Deflection rate is the metric everyone quotes, and on its own it’s misleading. An agent can post a beautiful deflection number by refusing to escalate — trapping customers until they give up — and that shows up as “resolved” while your CSAT quietly craters. The honest scoreboard watches both sides of the boundary.

The Agentforce observability tooling is where you watch it: escalation rate by topic, what triggered each handoff, how long customers waited on the human side, and — the number that actually matters — whether escalated customers were resolved without repeating themselves. If one topic escalates far more than the rest, that’s a topic-design or grounding gap to fix upstream. If escalations spike after hours, your fallback branch is doing the work and you may need staffing or an async path. You can’t improve a handoff you don’t instrument, and this is the instrumentation.

Before launch, this belongs on the testing plan too: run the escalation paths deliberately, confirm the transcript and case actually arrive on the rep’s screen, and test the no-agent-available branch specifically, because that’s the one that never comes up in a happy-path demo and always comes up in production.

The takeaway

The handoff is the least demoed and most decisive part of an Agentforce service deployment. The standard Escalation topic decides when to hand off — tune it to your policy so it fires on explicit requests, repeated failure, out-of-scope intent, and risk, rather than a vendor default. The outbound Omni-Channel flow does the actual transfer, and it’s the real build: check availability, route by skill through the queues you already run, and define the fallback for when nobody’s there. Above all, carry the context — transcript, summary, sentiment, and the case and record IDs — so the customer never explains their problem twice. Then instrument both sides of the boundary so your deflection number is honest. An agent that escalates gracefully feels like a front door; one that escalates into a void feels like a trap, and the difference is entirely in this build. Designing agents that resolve what they can and hand off cleanly what they can’t is the core of our Agentforce work.

Understanding the basics

How does an Agentforce agent escalate to a human?

An Agentforce Service Agent uses a standard Escalation topic to recognize when a conversation should leave the agent, and then performs the transfer through an outbound Omni-Channel flow that you configure in the agent’s connection settings. On enhanced messaging channels, that flow routes the conversation to a rep or a queue using your existing Omni-Channel routing — the same queues, skills, and capacity rules that govern human-initiated transfers. The escalation carries the conversation’s context with it, so the human who accepts the transfer sees the transcript, a summary, the sentiment, and any case created during the conversation.

What context gets passed to the human agent during a handoff?

A well-built handoff passes the full transcript, a short summary of the intent and current state, a sentiment readout, and the relevant record IDs — including any case the agent opened mid-conversation and the contact, order, or asset it was working with. These are configured as explicit inputs on the escalation action, not incidental metadata, which is why designing that payload matters: when it rides along with the routed work item, the customer experiences a seamless handoff, and when it doesn’t, they have to repeat everything to the human who picks up.

Why is the outbound Omni-Channel flow the hard part of Agentforce escalation?

Because the escalation topic only decides that a handoff should happen; the outbound Omni-Channel flow decides how. That flow has to check whether a human is available, choose the right queue or skill based on intent, account, and language, handle the case where nobody is online with an explicit fallback like a callback or an async case, and attach the conversation context to the routed work item. It rides on your existing Omni-Channel infrastructure, so you’re extending routing you already run rather than building a new one — but the availability check, the routing logic, and the fallback branch are all real design work that a happy-path demo never exercises.

---

Building an Agentforce agent and worried the handoff is an afterthought? It usually is — and it’s the part customers remember. Talk to us — designing escalation that routes to the right human with full context is a normal part of how we ship service agents.