Agentforce and Service Cloud: what actually connects to what

Every vendor diagram of this shows four boxes: customer, agent, knowledge, human. It is not wrong. It is just missing every decision that determines whether the thing works.

This is the topology as we actually build it, and the reason to draw it properly is that each connection carries a design choice, and getting one wrong produces a failure that looks like a different problem entirely.

#The four surfaces

Agentforce touches Service Cloud in four places, and it is worth separating them because they have different permission models, different failure modes and different owners.

Most implementation problems can be located to one of these four rows, and the diagnosis is usually faster once you ask which surface failed rather than why the agent got it wrong.

#Channel: identity decides everything downstream

The single most consequential input is not the customer's question. It is whether the channel knows who they are.

An authenticated web session inside a customer portal arrives with a verified contact, an account, and an entitlement. The agent can answer questions about this customer's orders, and the sharing model does the work of bounding what that means. An inbound email or an unauthenticated chat arrives with an email address and a claim, and neither is proof.

That distinction has to be designed rather than discovered. Otherwise you build an agent that answers account-specific questions beautifully in your portal, extend it to an unauthenticated channel because the intents look the same, and quietly create a way to enumerate customer data by guessing email addresses.

The practical pattern is a three-tier model. Anonymous intents get general information only. Weakly identified intents get non-sensitive, account-scoped answers behind a verification step. Strongly identified intents get the full picture.

#Grounding: two access models, not one

The agent reads from two distinct places, and the mistake we see most often is assuming one permission model governs both.

Record data is bounded by the sharing model, through the agent's running user. This is well understood and behaves the way Salesforce administrators expect.

Knowledge is bounded separately, by data categories and channel visibility. An article marked visible to a public channel is available to the agent regardless of how carefully the record sharing was configured. So an agent can be correctly restricted from viewing a case and still quote an internal troubleshooting article that was never meant to leave the support team.

Audit both. The question to answer is not "what can the agent see" but "what can the agent see, through each of the two paths, and are those answers the same". If you cannot state both, that is permission set debt surfacing in a new place.

#The case object: when does it get created?

This is the decision that most affects reporting, and it is usually made by accident.

Create on first contact. Every conversation becomes a case. Volume reporting is complete and comparable with the pre-agent baseline. The cost is that case counts inflate with conversations that were a single question and never needed a case, which distorts every per-case metric you have and makes the agent look like it increased workload.

Create on escalation. Only conversations that reach a human become cases. Case data stays meaningful, per-case metrics stay comparable, and the trade is that you lose the record of what the agent handled unless you log it somewhere else.

Create on qualifying condition. A case is created when the conversation meets a defined test, such as touching a complaint, or exceeding a turn count. This is the most work to define and the version most orgs land on eventually.

Whichever you choose, log agent conversations somewhere regardless. Deflection cannot be measured against conversations you did not record, and the argument about whether the agent is working will be unwinnable without that data.

#Actions: read wide, write narrow

Grounding reads and action writes deserve different rules.

Reading widely is generally safe and often necessary, because the whole value of the agent is assembling context a human would have collected across four tabs. Writing is where damage happens, and the discipline is one action, one job, its own permission surface.

The specific pattern worth adopting: every irreversible action gets its own guardrails at the action layer, not at the agent layer. Whether a case closure, a refund or an entitlement change is triggered by an agent, a Flow or a person, the validation and the logging live in the action. Put them there and they hold no matter what invokes them later, which matters because something else will.

#Escalation: the handover is the product

Omni-Channel does the routing, and the routing is the easy part. Three things decide whether an escalation feels like help or like being passed around.

Triggers. Explicit request, repeated failure to resolve, low retrieval confidence, and at least one business rule with nothing to do with confidence: a mention of a regulator, a complaint, financial hardship, or any vulnerable-customer signal your organisation recognises. Confidence-based triggers alone will miss the cases that matter most.

Routing. The escalation should reach someone with the skill and capacity to help, which is ordinary Omni-Channel work, except that agent-escalated conversations often need a different skill profile than the same channel's normal traffic. The easy questions have already been handled.

Context. The human needs what the customer said, what the agent tried, and what it could not resolve, visible without opening anything. If the customer has to repeat themselves, the escalation has cost more goodwill than the deflection saved, and you would have been better off routing directly.

#Voice changes the shape

Adding voice to this topology is not the same design with a different channel attached, and treating it that way is a common and expensive assumption.

Three differences matter. Latency becomes user-visible in a way it never is in chat, because silence on a call is uncomfortable after about two seconds, and a multi-action retrieval that reads as responsive in a chat window reads as a dropped call on the phone. Voice actions consume 30 Flex Credits against 20 for a standard action, so the same conversational shape costs half again as much. And there is no scrollback: a customer cannot re-read what was said, so an answer that is technically complete but structured as a paragraph fails, where the same content as three short sentences works.

The design consequence is that voice intents should be narrower than chat intents, not the same set delivered differently. Anything requiring the customer to hold four facts in their head while the agent finishes is a chat intent.

#Data 360 as a grounding source

Knowledge answers policy questions. It cannot answer what this customer bought, when, and whether it has been delivered, and that is where a large share of real service volume sits.

Those answers come from records, and when the records are spread across Salesforce, an ERP and a logistics platform, the unification work sits in Data 360 rather than in the agent. This is the point at which a service agent project acquires a data project, and it is better to discover that during design than during build.

The architectural question to settle early is whether the agent reads unified data or calls out live. Unified data is fast, consistent and can be stale. A live call is current and introduces a dependency that will eventually be unavailable while the agent is mid-conversation. Most service intents tolerate slightly stale data far better than they tolerate an outage, which usually settles it, but it should be settled deliberately per intent rather than once globally.

#Testing the topology

Each surface needs its own test, and testing the agent end to end will not exercise them.

Channel tests run the same intent through every channel and confirm the identity handling differs correctly. The specific thing to prove is that an account-scoped intent refuses on an unauthenticated channel. Most teams never run this test, because in the build environment they are always signed in.

Grounding tests verify both access paths independently. Confirm the running user cannot see records it should not, then separately confirm the agent cannot surface Knowledge articles restricted to internal channels. Passing one is not evidence about the other.

Action tests exercise each action in isolation with deliberately wrong inputs, because the agent will eventually supply wrong inputs and the action's own validation is what stands between that and a bad write.

Escalation tests need a real human on the other end at least once. Reading a handover in a test tool tells you the payload arrived. It does not tell you whether the person receiving it can understand what happened without asking the customer to repeat themselves, which is the only thing that actually matters.

#Retrofitting onto an existing org

Greenfield is rare. Most of this work lands on a Service Cloud org that has been running for years, which changes the sequence in two ways.

First, the case model already exists and probably carries a decade of reporting expectations. Introducing agent conversations into that data set will break comparisons unless the creation decision above is made deliberately and the historical baseline is preserved. Agree it with whoever owns service reporting before go-live, because they will notice within a week and their objection will be legitimate.

Second, existing automation already fires on case creation and update. An agent creating or updating cases will trigger all of it, including assignment rules, entitlement processes and notifications written on the assumption that a human was involved. Auditing what runs on those events is unglamorous, and it is the step whose omission produces the strangest go-live incidents.

#Where the topology usually breaks

Three failures, each locatable to a surface.

A channel failure looks like the agent answering account questions for someone whose identity was never verified. It is found by testing intents against each channel rather than against the agent.

A grounding failure looks like a confidently wrong answer, and the fix depends on which of the three grounding problems you have. We set those out in what separates an Agentforce rollout that is still running in six months, and the pre-launch version is the grounding checklist.

An escalation failure looks like good deflection numbers and rising repeat contacts. That combination is the signature, and it is covered in deflection that does not cost you the customer.

#What to draw before you build

One diagram, four surfaces, and for each channel a note of the identity strength it establishes. Then, for each in-scope intent, the minimum identity strength it requires and the two access paths it reads through.

That fits on a page, it takes an afternoon, and it is the artefact that makes the permission conversation concrete rather than theoretical. It is also the thing an auditor will ask for, and having written it before launch is considerably more comfortable than assembling it afterwards.