Get in Touch

Category: Salesforce AI

  • Giving an agent permission to act: designing the guardrails before Agentforce gets write access

    Every Agentforce rollout starts the same way: read access first, a few topics, a demo that goes well. Then someone asks the obvious next question. Can it actually update the case? Can it process the refund, not just look it up? That’s the moment the project gets real, and it’s also the moment most teams realise they don’t have an answer ready.

    I’ve sat in that meeting more than once. The agent works fine in read-only mode because read-only mode forgives almost everything. A bad query returns the wrong record and someone notices on screen. Write access doesn’t forgive. A bad write closes the wrong case, double-refunds a customer, or fires an email to the wrong contact, and by the time anyone notices, it’s already happened.

    Why write access changes the risk profile

    A human agent who makes a mistake usually makes one mistake. They’re slow, they second-guess themselves, and they ask a supervisor when something feels off. An AI agent with write access and a bug in its reasoning can make the same mistake a hundred times in the time it takes you to notice the first one. That’s the actual argument for guardrails: not that the agent is untrustworthy in some abstract sense, but that its error mode is different in kind from a human’s. Scale is the risk, not intent.

    This is why “it worked in the demo” tells you almost nothing about whether it’s safe to give an agent write access. The demo ran one happy path, once, with someone watching. Production runs every path, continuously, with nobody watching the individual transaction.

    The guardrails that actually matter

    Scope the permission set to the job, not the object

    The standard Salesforce instinct is to grant edit access on a case or an account and call it done. Don’t. Build a permission set that matches exactly what the agent’s topic is meant to do: update status on a specific case type, not edit any field on any case. If the agent’s job is to update delivery status on an order, it has no business editing the billing address on that same record, even though both fields sit on the same object. Narrow the permission set until the agent literally cannot do the thing you didn’t intend it to do, rather than trusting it won’t try.

    Put validation in the data layer, not the prompt

    A system prompt that says “don’t process refunds over $500” is an instruction, not a control. Agents misread instructions, and a cleverly worded customer message can talk an agent out of a soft rule faster than you’d expect. The actual limit belongs in a validation rule, a flow, or an Apex trigger on the object itself, somewhere the agent can’t negotiate with it. Let the agent attempt the action. Let the platform reject it if it breaks the rule. The agent should never be the only thing standing between a customer and a bad outcome.

    Build an approval step for anything you can’t undo

    Some actions are cheap to reverse: updating a case description, adding a note, re-routing a routine enquiry. Others aren’t: a refund, a contract change, anything that sends an external communication. For the second category, the agent should request the action and a human should approve it before it fires, at least until you’ve got enough production history to trust the pattern. This slows the agent down on the actions that matter and leaves it fast on the ones that don’t, which is the right trade.

    Log what it did and why, not just that it did something

    Standard field history tells you a value changed. It doesn’t tell you which topic triggered the change, what the customer said that led to it, or what the agent’s reasoning was at the point of action. Without that, every incident review turns into guesswork. Set up logging that captures the triggering input, the action taken, and a short reasoning trace, and keep it somewhere a support team can query quickly. The first time an agent does something wrong in production, you’ll want this a lot faster than you’ll want to build it.

    Testing before the switch flips

    Testing an agent with write access isn’t the same exercise as testing a flow. A flow does the same thing every time you give it the same input. An agent can take a slightly different path through the same conversation twice, so a single pass of test cases won’t tell you what you need to know. Run the same scenario multiple times with small variations in phrasing and check that the outcome stays within bounds, not that it’s identical. Then run the scenarios you hope never happen: an angry customer trying to talk the agent into an exception, a request that sits right on the edge of what the permission set allows, a malformed input that a human would recognise as odd. If the agent’s write access only gets tested on clean, polite inputs, you’ve tested the demo, not the job.

    What skipping this actually costs

    I’ve seen teams treat guardrails as the thing you add once the agent is working, not before. That ordering is backwards, and it’s backwards because of how these failures surface. A flow with a bug usually fails loudly and immediately. An agent with a subtly wrong permission set or a missing validation rule can run correctly for weeks and then fail on exactly the input nobody tested for, at a point where it’s already touched hundreds of real records. Retrofitting guardrails after that happens means an incident review, a rollback, and a much harder conversation with whoever owns the business outcome than the one you’d have had by building the guardrails first.

    None of this is an argument against giving Agentforce write access. It’s an argument for treating write access as a separate decision from read access, with its own permission design, its own validation layer, its own approval points, and its own test plan. Get that sequencing right and the agent earns broader access on a track record you can actually point to. Skip it, and you’re trusting a demo to predict production, which it never does.

  • Hosted MCP servers on Salesforce: what they are and why they matter for integrations

    Every integration I’ve built on Salesforce over the last decade has followed the same shape: something outside the platform calls in, or Salesforce calls out, through an endpoint one of us designed and documented ahead of time. Hosted MCP servers break that assumption. They let an AI agent discover what a Salesforce org can do at runtime, without a developer having written a bespoke contract for that exact conversation.

    That’s a bigger shift than the release notes make it sound. Worth working through carefully, because I think most Salesforce teams are going to meet this feature through an Agentforce demo rather than through an architecture review, and that’s the wrong entry point.

    What MCP actually is

    Model Context Protocol is an open standard for letting an AI model discover and call “tools”, actions with a name, a description, and a defined input schema, without the model’s creator having to hard-code anything about your system. A hosted MCP server is Salesforce exposing a set of its own capabilities (objects, Flows, Apex actions) as that same kind of tool, running on Salesforce’s infrastructure rather than something you stand up yourself.

    Before this, if you wanted an AI assistant to touch Salesforce data, you built a custom action, wired it into Agentforce’s topic and action model, and that action worked inside Agentforce and nowhere else. A hosted MCP server is protocol-level instead. Any MCP-compatible client, Claude, a custom agent, another vendor’s assistant, can connect to it and get the same tool definitions. You describe the capability once. Where it gets consumed is no longer your problem to solve per client.

    What’s actually exposed

    In practice, a hosted MCP server surfaces three kinds of things: standard and custom object operations (query, create, update, following the same field-level security and sharing rules the calling user already has), invocable Apex actions you’ve built and marked for exposure, and Flows set up to run as autonomous or template actions. None of that is new capability. It’s existing automation and data access, described in a format an AI client can read and reason about without you writing a new client library for every consumer.

    How this differs from what you’ve already built

    If you’ve worked with External Services, this will feel familiar at the surface and different underneath. External Services imports an OpenAPI spec so Flow and Apex can call an external system through a predictable, versioned contract. A hosted MCP server runs the comparison the other way: Salesforce is the thing being described, and the consumer is an AI model deciding, at runtime, which tool to call and with what arguments, based on a natural-language request it’s trying to satisfy.

    That runtime decision-making is the part integration architects need to sit with. A REST callout fails loudly and predictably when the contract changes. An MCP tool call can “succeed” technically while the model has picked the wrong tool, or the right tool with slightly wrong arguments, because it inferred intent from a prompt rather than executing a line of code you wrote. The failure mode moves from the network layer to the reasoning layer, and most of our existing monitoring doesn’t look there yet.

    Authentication doesn’t get simpler

    It’s tempting to assume MCP abstracts away auth the way it abstracts away the API shape. It doesn’t. Every call still runs as a specific authenticated user or connected app, with whatever permission set, sharing rules, and field-level security that identity carries. The protocol changes how the tool is discovered and invoked. It changes nothing about who’s allowed to see what. If anything, this is where I’d spend the most review time: a hosted MCP server that’s scoped too broadly hands an AI client the same blast radius a careless integration user would have, except now a model is deciding which actions to fire, not a developer who read the spec first.

    Where this fits in your integration patterns

    I’d place hosted MCP servers as a third pattern alongside request-reply and fire-and-forget, not a replacement for either. A contact-centre team I worked with recently had this exact conversation: should a new case-triage action be a Flow-triggered automation, an Apex REST endpoint for an external system, or an MCP tool for an AI agent to call directly? The answer came down to who initiates the call. If a known system triggers it on a schedule or an event, build the automation or the REST endpoint, because you want a fixed, testable contract. If the point of the feature is that a conversational agent decides when and whether to act, based on context it’s reasoning about in the moment, that’s the MCP shape, and forcing it into a traditional integration just reintroduces the rigidity you were trying to get away from.

    Testing looks different too

    Standard integration testing checks that a known input produces a known output. MCP tool testing has to check that an AI client, given a realistic range of phrasing, picks the right tool at all, and picks it with sane arguments. That’s closer to the evaluation work you’d do on a chatbot than to Apex test coverage. If your org’s current release process doesn’t have anyone doing that kind of testing, hosted MCP servers are the forcing function that makes it necessary, not optional.

    What I’d actually do before turning one on

    Scope the connected app or permission set behind the MCP server as narrowly as the use case allows, not as broadly as “it might be useful later”. Write tool descriptions as carefully as you’d write a public API’s documentation, because the model’s tool-selection accuracy depends entirely on how clearly you’ve described what each action does and when it should be used. And put someone on the hook for reviewing what the agent actually called in production, not just whether the calls succeeded. A hosted MCP server that silently lets an agent update the wrong records, with valid permissions and no error thrown, is a worse outcome than an integration that fails and pages someone.

    None of this makes hosted MCP servers something to avoid. It makes them something to design the same way you’d design any integration that can change data: start from what should be allowed, not from what’s technically possible, and build the boring guardrails first.

  • Agent Script and the Agentforce Vibes IDE: what changes for Salesforce developers

    Every Agentforce build I’ve looked at eventually hits the same wall: the logic that decides what an agent does lives in three or four different places at once. A topic here, an instruction there, an Apex action buried in a class nobody on the business side will ever read. Agent Script is Salesforce’s attempt to collapse that into something a human can actually look at and reason about. The Vibes IDE is the authoring layer sitting on top of it. Together they change less about what an agent can do and more about who gets to build it and how fast.

    What Agent Script actually is

    Strip away the branding and Agent Script is a structured, readable way to describe agent behaviour: what the agent is responsible for, what it should ask before acting, which actions it’s allowed to call, and under what conditions it hands off to a human. It compiles down to the same topics, instructions and actions Agentforce has always run on. The difference is that it’s written and reviewed as text, not assembled by clicking through five different setup screens and hoping the configuration matches the mental model in your head.

    That matters more than it sounds like it should. Right now, auditing an Agentforce agent means opening the Topics list, then the Actions list, then whatever Flow or Apex sits behind each action, then trying to hold all of it in working memory at once. A text-based definition means you can diff it, version it, and review it the way you’d review a pull request. For a technical lead, that’s the real unlock: code review stops being a special case you do for Apex and starts applying to agent behaviour too.

    Where this bites in practice

    I’ve seen plenty of orgs where the person who built the original agent configuration has moved teams, and nobody left can explain why a particular topic routes the way it does. Click-based configuration doesn’t leave a trail. A script does. Even a mediocre commit history beats no history at all.

    Where Vibes IDE fits

    Vibes IDE is the authoring experience: describe what you want the agent to do in plain language, get a working scaffold back, then drop into the underlying Agent Script to tighten it up. It’s the same pattern that’s shown up across developer tooling generally over the past couple of years: natural language gets you eighty percent of the way, and a competent engineer closes the gap on the remaining twenty. The interesting part isn’t the generation step. It’s that the output is inspectable and editable rather than a black box you either accept or throw away.

    For admins and junior developers, this lowers the floor for getting something working. For a technical lead, it changes what review looks like. You’re no longer just checking whether an agent answers correctly in a demo. You’re reading generated script the same way you’d read a junior developer’s first pass at a trigger: is the scope right, does it fail safely, does it ask for confirmation before anything irreversible.

    What doesn’t change

    None of this touches the actual hard problems. An agent built from a beautifully clean script still fails if the underlying data model is messy, if field-level security is inconsistent across the objects it touches, or if nobody’s defined what “done” means for the task it’s handling. A contact-centre agent that’s supposed to look up order status is still at the mercy of whatever gap exists between the Order object and the Case object in your org. Agent Script makes the agent’s logic legible. It does nothing for the data the agent is reasoning over.

    Testing doesn’t get easier either, just more structured. You still need the same discipline you’d apply to any automation: a set of representative inputs, a way to assert on outcomes, and a regression suite that runs before every change ships. The format changed. The job didn’t.

    There’s a governance question hiding in here too. A script that’s easy to generate is also easy to regenerate, and it’s tempting to let an agent’s permissions grow every time someone asks Vibes IDE for “one more capability.” I’d treat any change that expands what an agent can write to, not just what it can read, as a release event, not a prompt. That’s a small discipline to add, and it’s the difference between an agent that’s genuinely useful and one that’s quietly been granted more reach than anyone signed off on.

    What a technical lead should actually do with this

    Three things, in order of how quickly they pay off.

    • Treat Agent Script output the way you’d treat any generated code: review it before it ships, don’t just trust the demo. The gap between “answers the happy path” and “handles the edge cases a real customer will hit” is where most agent failures live.
    • Put agent definitions under the same version control and release process as everything else. If Agent Script gives you text, there’s no excuse for configuration drift between sandbox and production anymore.
    • Use Vibes IDE for the first draft, not the final build. It’s genuinely useful for getting unstuck on structure. It’s not a substitute for understanding what the agent is allowed to do and why.

    None of this is a reason to slow down adoption. A contact-centre team I worked with spent most of an early Agentforce build arguing about Topic boundaries in a spreadsheet, because nobody could see the whole picture at once. Something that turns that argument into a reviewable document is worth having, even before it generates a single line of anything. The value isn’t that the agent gets smarter. It’s that the people building it finally have something solid to point at when they disagree.

  • Testing AI agents before production: what “agent QA” actually looks like on Salesforce

    Every Salesforce release has a testing ritual attached to it. Write the Apex tests, hit 75% coverage, run the regression pack, ship. Nobody loves it, but everyone knows the shape of it. Agentforce doesn’t fit that shape. Most teams find that out a week after go-live, when an agent tells a customer something that isn’t true and nobody can explain why, or point to a test that would have caught it.

    Coverage percentage tells you nothing about an agent

    Apex testing asks a narrow question: given this input, does the code return the expected output, every time, deterministically. An Agentforce topic doesn’t work that way. Ask the same question two different ways and you can get two different answers, both reasonable-sounding, only one of them correct. Coverage percentage can’t catch that. It was built to catch broken logic, not bad judgment.

    That’s the real shift. You’re no longer testing whether code executes correctly. You’re testing whether a system that reasons in natural language reaches the right decision often enough, fails safely when it doesn’t, and never does anything it shouldn’t have permission to do in the first place.

    What actually needs testing

    Four things, roughly in order of how often they break in practice:

    • Topic and intent routing. Does the agent correctly identify what the customer is actually asking for, including when they phrase it badly, use industry jargon wrong, or ask two things in one message?
    • Grounding. When the agent answers a factual question, is it pulling from an actual record, a knowledge article, a Data Cloud object, something real, or is it filling the gap with something plausible-sounding?
    • Action execution. When the agent decides to do something (update a case, trigger a refund, escalate), does it pass the right parameters, respect field-level security, and stop when it should?
    • Escalation and refusal. Does the agent know when to hand off to a human, and does it actually do that instead of attempting the task anyway because it sounded confident it could?

    Most teams I’ve seen test the first one reasonably well, because it’s the one that shows up in a demo. The other three get skipped, and they’re the ones that cause the incidents.

    Build a test set before you build the agent

    The teams that get this right treat the test set as a deliverable in its own right, written before a single topic is configured. Not after. A good test set for a contact-centre agent typically has three layers.

    Golden conversations

    A fixed set of real (anonymised) conversation transcripts, maybe 30 to 50 to start, covering the common paths and the awkward ones: the customer who’s annoyed, the one who gives contradictory information, the one who asks for something the agent genuinely shouldn’t be allowed to do. Run these against every build before it moves environments. If a change to one topic quietly breaks the behaviour of another, this is what catches it.

    Adversarial prompts

    Deliberately awkward inputs designed to find the edges: prompt injection attempts buried in a case description, a customer trying to get the agent to override a business rule by rephrasing the request, a question that sounds like it’s in scope but actually needs a human judgment call. If nobody on the team is writing these on purpose, someone outside the team will find them for you, in production, and it won’t go well.

    Regression baselines

    A snapshot of expected responses for a stable set of inputs, re-run on a schedule and whenever the underlying model, prompt, or grounding data changes. This is the part most orgs skip entirely because nothing in the standard release process asks for it. Without it, a model update from the platform vendor can shift agent behaviour and nobody notices until a customer complains.

    Where this breaks in practice

    A pattern I’ve seen more than once: a contact-centre team pilots an agent on a narrow, well-defined topic, like order status lookups, and it performs well. Confidence builds. The scope expands to billing questions, then to refund processing, faster than the test set grows with it. Three months in, the agent is handling cases nobody explicitly tested for, because the team that approved the expansion assumed “it’s working” meant the same thing at the new scope as it did at the old one. It didn’t. The grounding data for refunds wasn’t as clean as the order data, and the agent started answering confidently from stale records.

    The fix isn’t slower rollout for its own sake. It’s tying scope expansion to test set expansion, explicitly, as a release gate. If the topic list grows, the golden conversations and adversarial prompts grow with it, before go-live, not after the first complaint.

    Who actually owns this

    This is where a lot of orgs stall, because it doesn’t map cleanly onto an existing role. A Salesforce admin can configure a topic and wire up an action, but evaluating whether an agent’s judgment is sound on ambiguous inputs isn’t a configuration skill. A developer can write the Apex action behind an agent action and unit test the Apex itself, but that only proves the action works when called correctly, not that the agent calls it correctly.

    In practice, agent QA needs someone who understands both the business process well enough to write realistic test conversations and the platform well enough to read a reasoning trace and spot where it went wrong. On a lot of teams that’s the technical lead, by default, because nobody else has both halves. Worth naming explicitly rather than letting it fall to whoever’s free.

    A practical go-live checklist

    Before any Agentforce topic moves to production, I want to see:

    • A documented test set covering the golden paths, the awkward paths, and at least a handful of adversarial inputs, with expected outcomes written down in advance, not judged after the fact
    • A grounding check confirming every factual claim the agent can make traces back to an actual object, field, or knowledge source
    • Explicit verification that every action the agent can trigger respects the same field-level security and sharing rules a human user would be bound by
    • A named owner for the regression suite, and a trigger for re-running it (model change, prompt change, data model change, scope expansion)
    • A rollback plan that doesn’t depend on someone noticing a bad answer in real time

    None of this is exotic. It’s the same discipline Salesforce teams already apply to a risky Apex deployment, just aimed at a system where “the code is correct” is no longer the question that matters. The teams struggling with Agentforce adoption right now aren’t struggling because the platform doesn’t work. They’re struggling because they brought a deterministic testing mindset to a probabilistic system, and the gap between those two things is exactly where production incidents live.

  • Agentforce Coworker in practice: what changes when an AI teammate gets its own queue

    Give Agentforce its own queue and something changes that most teams don’t plan for. It’s not the AI accuracy, and it’s not the setup. It’s the moment a case sits in a queue with no human attached to it, waiting on a decision an agent made, and nobody in your support team can immediately tell you why that decision got made.

    Agentforce Coworker (the setup where an agent operates as a routable teammate, with its own queue, its own skill set and its own workload) is a genuinely different operating model from Agentforce as a chat widget bolted onto a help page. A chat widget fails politely: the customer gets a bad answer, or no answer, and either way a human was never that far from the interaction. A Coworker in a queue is making the same kind of call your Tier 1 agents make: accept this case, resolve it, escalate it, or sit on it. The difference is nobody’s watching over its shoulder in real time.

    What actually changes when the agent has a queue

    Three things shift the moment you give Agentforce a real queue instead of a chat window.

    Routing logic has to treat the agent as a resource, not a fallback

    Most orgs I’ve worked in built Omni-Channel routing around humans: skills, capacity, presence status. Bolting an AI queue onto that model as an afterthought usually means it only picks up the leftovers nobody wants, which defeats the point. If Agentforce Coworker is meant to carry real volume, your routing rules need to know what it’s actually good at (password resets, order status, simple entitlement checks) and route those cases to it first, not last. That’s a configuration change, but it’s also a trust decision your contact-centre lead has to sign off on, and it’s worth writing down explicitly rather than letting it drift out of whatever the default routing config happened to do.

    Escalation needs a real contract, not a vibe

    When a human agent is stuck, they know it, and they ask for help or bump the case up. An AI agent doesn’t have that instinct unless you build it in. I’ve seen Agentforce actions configured with no explicit escalation condition at all, just an implicit assumption that it’ll “figure out” when it’s out of its depth. It won’t, reliably. You need hard boundaries: confidence thresholds, specific topics it’s never allowed to resolve (refunds over a dollar value, anything touching a complaint flagged as a formal grievance), and a clean handoff that carries full context to the human who picks it up. Build that contract before go-live, not after the first case that goes sideways.

    Case ownership and reporting assume a person on the other end

    Most Salesforce orgs have years of reports, dashboards and SLA rules built around the assumption that a case owner is a person with a name, a manager and a performance conversation. Put Agentforce in the owner field and a surprising number of those reports quietly break or mislead: average handle time calculations that don’t account for the agent resolving in nine seconds, SLA breach alerts that fire because nobody built an exception for machine-resolved cases, team leaderboards that either exclude the AI entirely or compare it unfairly against a junior agent six months into the job. None of this is hard to fix. All of it needs to actually get fixed before the dashboards go in front of a steering committee.

    The guardrail that matters most: what the agent is allowed to decide alone

    The single highest-leverage design decision in a Coworker deployment is drawing the line between “the agent resolves this and closes the case” and “the agent prepares the answer, a human approves it.” Too many teams treat this as a binary switch for the whole queue. It isn’t. It’s a per-topic decision, and it should be reviewed on a cadence, not set once at launch and forgotten.

    A practical starting point I’d recommend to a client: anything reversible, low-value and well-bounded (status lookups, basic troubleshooting steps, scheduling) gets full autonomy from day one. Anything irreversible, financial, or legally sensitive goes through human approval for the first few months regardless of how confident the agent seems in testing. You loosen that over time based on actual production accuracy, not sandbox demo performance, which almost always looks better than it should.

    Where this actually pays off

    I’d be skeptical of a business case built purely on headcount reduction. The more durable value I’ve seen in contact-centre work is consistency: an AI teammate handling the same category of case the same way every single time, at 2am on a Sunday as reliably as 11am on a Tuesday, without the variance you get across a roster of forty human agents with different experience levels and different days. That consistency shows up in SLA compliance and first-contact resolution rates faster than it shows up in a cost line.

    It also changes what you ask your human agents to do. If the straightforward 40% of volume moves to a Coworker queue, your remaining human team is left with the harder, more ambiguous cases disproportionately. That’s good for engagement if you plan for it (more interesting work, more authority to resolve things end to end) and genuinely bad for morale if you don’t (every case feels harder, nothing feels like a quick win anymore). Worth raising with whoever owns the contact centre before the agent goes live, not after the engagement scores drop.

    Before you flip the switch

    If you’re scoping this for a client or your own org, get three things nailed down before Coworker goes into production: the routing logic that decides what it sees, the escalation contract that decides when it bails out, and the reporting changes that stop your dashboards from silently misrepresenting what actually happened. Skip any of the three and you’ll find out about it from a customer complaint or a confused operations manager, rather than from a test case.

  • What Agentforce actually changes for a contact-centre team

    Every Salesforce contact-centre client I’ve spoken to this year has the same question in some form: what does Agentforce actually do for us, beyond the demo? The demo shows a bot resolving a billing query in four seconds flat. The real question is whether that changes how your team spends Monday morning, and for most teams the honest answer is: it changes less than the pitch deck suggests, and more than the skeptics expect, and the gap between those two outcomes comes down to work nobody wants to do first.

    The part that actually shifts

    Agentforce doesn’t replace your case queue. It sits in front of it. For a contact-centre team, the meaningful change happens in three places, and they’re not the three places most rollouts focus on first.

    Tier-1 deflection on structured questions

    Password resets, order status, “where’s my delivery,” account balance lookups. These are the requests that already had clear resolution paths before Agentforce existed, which is exactly why they’re the easiest wins. A contact-centre team I worked with had roughly a third of inbound cases sitting in this bucket. None of them needed judgment. All of them needed correct data retrieval and a clean handoff when the answer wasn’t in the knowledge article. That’s the actual value: not intelligence, just speed on things that were never hard.

    Agent-facing copilot, not customer-facing bot

    The bigger shift for most teams isn’t the customer-facing agent at all. It’s giving your human agents an Agentforce-powered assistant that drafts case summaries, suggests the next best action from case history, and pulls relevant knowledge articles into the console while the agent is still on the call. Your agents stop context-switching between four tabs to reconstruct what happened last time this customer called. That alone can cut average handle time more than any chatbot deflection number, and it’s far less risky to ship because a human is still making the final call.

    Case triage and routing that reads intent, not just keywords

    Omni-Channel routing has always been rules-based: skill, queue, priority field. Agentforce lets you route on inferred intent from the case description itself, which matters when your intake form is a free-text box and half your customers describe a billing problem as “app is broken.” That’s a real improvement over keyword-matching rules that break the moment someone phrases things unexpectedly.

    What doesn’t change, no matter how good the model is

    Agentforce is only as good as the data model underneath it, and this is where most rollouts stall. If your Case object has inconsistent record types, your Knowledge articles haven’t been updated since a platform migration two years ago, or your entitlement and SLA data lives in three different places with three different definitions of “resolved,” Agentforce will confidently generate wrong answers at scale instead of slow wrong answers one at a time. That’s a worse outcome than doing nothing.

    I’d put the prerequisite list at four items, and none of them are exciting:

    • A Knowledge base that’s actually maintained, with clear article ownership and a review cadence, not a folder of articles nobody’s touched since go-live.
    • Case data with consistent, meaningful field values. If “Category” is a free-text field with 400 unique entries because agents type whatever they want, Agentforce can’t reason over it.
    • Clear escalation boundaries defined before launch, not discovered after a customer complaint. What can the agent decide alone, and where does it have to hand off?
    • A test plan that covers edge cases, not just the happy path demo. Ambiguous requests, angry customers, multi-issue cases. That’s where trust gets built or lost.

    None of this is Agentforce-specific. It’s the same governance work that determines whether any automation succeeds on Salesforce, going back to the first workflow rule anyone ever built. Agentforce just makes the cost of skipping it visible faster, because a bad automated answer reaches a customer directly instead of sitting in an agent’s queue waiting for a human to catch the error.

    The metric that actually tells you if it’s working

    Deflection rate is the number every vendor leads with, and it’s the wrong one to optimise alone. A deflection rate can go up while customer satisfaction goes down, if the bot is closing cases that should have been escalated. The metric worth tracking alongside it is reopen rate: how many “resolved” Agentforce cases get reopened or re-contacted within 48 hours. If that number climbs, you’re not deflecting work, you’re deferring it, and the customer is paying the cost in a second contact.

    For a Service Cloud team, I’d also watch first-contact resolution on the cases that do route to a human. If your agent copilot is working, that number should improve even on cases the bot never touched, because agents are spending less time hunting for context and more time actually resolving the issue.

    Where to start if you’re planning a rollout

    Don’t start with the customer-facing agent. Start with the agent-facing copilot on your highest-volume case type, because the blast radius of a bad suggestion is a human reviewing it, not a customer receiving it. Get your Knowledge base and case data clean enough to support that first, since it’s the same prerequisite work either way. Once that copilot is genuinely saving handle time (and you can prove it with a before-and-after number, not a feeling), extend into structured deflection for the narrow set of requests that already had deterministic answers.

    The teams that get burned are the ones that go straight to a customer-facing agent on a data model that was never designed for it, chasing a deflection number for a board slide. The teams that get real value spend the first few weeks somewhere less glamorous: cleaning up Case record types, retiring stale Knowledge articles, and defining what “resolved” actually means in their org. That work was overdue anyway. Agentforce just gave everyone a reason to finally do it.

  • Connecting Claude to Your Salesforce Org with Hosted MCP Servers (A Beginner-Friendly Walkthrough)

    If you’ve been copy-pasting record details or SOQL query results into Claude by hand, there’s now a much faster way. Salesforce runs its own set of “Hosted MCP servers,” and Claude can connect to them directly. Once connected, you can ask Claude things like “what’s the status of the Acme opportunity?” in plain English, and it will actually go look up the live answer in your org — not guess, not make something up.

    This guide assumes you’re comfortable clicking around Salesforce’s Setup menu but have never touched MCP, OAuth, or connectors before. I’ll explain each term the first time it shows up.

    First, some quick definitions

    What is an “org”? In Salesforce, “org” is short for organization — it just means one Salesforce instance/environment, i.e., the specific company database and configuration you log into. You might have a production org (the real, live system your company actually runs on) and separate sandbox or scratch orgs (copies used for testing, so nobody breaks the real thing while experimenting).

    What is MCP? MCP stands for Model Context Protocol. Think of it as a standardized way for an AI assistant like Claude to ask a piece of software (in this case, Salesforce) for information or to take an action, in a structured way the AI can understand — instead of you manually feeding it screenshots or exports.

    What is a “Hosted MCP server”? Normally, connecting an AI tool to a service like Salesforce would require someone to build and run a custom piece of connecting software. Salesforce has done that work for you and hosts it themselves — you just need to turn on the specific pieces (“servers”) you want to use and tell Claude where to find them.

    What is OAuth? It’s the standard, secure way one piece of software (Claude) asks permission to access your data in another piece of software (Salesforce), using your actual login rather than a shared password. When you “authorize” a connection, you’re logging into Salesforce yourself and clicking approve — Claude never sees or stores your Salesforce password.

    What’s a “Consumer Key”? A long, unique ID Salesforce generates that identifies the specific connection you’re setting up. You’ll copy this from Salesforce and paste it into Claude — it’s like a claim ticket, not a password.

    With that vocabulary out of the way, here’s the actual setup, in two parts: things you configure inside Salesforce, then things you configure inside Claude.

    What you’ll need before starting

    • System Administrator access to the Salesforce org (or a role with equivalent permissions) — a regular user account won’t be able to complete the Setup steps below
    • A Claude account with permission to add custom connectors (this is available on standard Claude accounts, not something special you need to request)
    • About 30-45 minutes — not because the steps are long, but because Salesforce has a built-in waiting period partway through (explained in Step 2)

    Part 1: Inside Salesforce

    Step 1: Activate the Beta Server

    1. Log into Salesforce and click the gear icon in the top-right corner, then click Setup. This opens Salesforce’s admin/configuration area — everything in this guide happens here, not in your normal working screens.
    2. On the left-hand side of Setup, there’s a search box labeled Quick Find. Type MCP Servers into it and click the matching result.
    3. Find headless-360 in the list of servers.
    4. Click Activate.

    A word of caution here: activating a server is a real decision about what data becomes accessible to an AI tool, not a harmless toggle. If you’re setting this up for a company org rather than just your own personal sandbox, loop in whoever owns security/compliance decisions before activating anything beyond read access.

    Step 2: Create an “External Client App” (this is the OAuth setup)

    This step registers Claude as an app that’s allowed to ask for permission to connect — think of it as Salesforce’s version of “add a new sign-in method.”

    1. Back in the Setup Quick Find box, search for External Client App Manager and click it.
    2. Click New External Client App.
    3. Under Basic Information, fill in:
      • App Name: anything descriptive, e.g. “Claude Connector”
      • API Name: this usually auto-fills based on the App Name
      • Contact Email: your email address
    4. Find and expand the section called API (Enable OAuth Settings). Check the box Enable OAuth.
    5. In the Callback URL field, paste exactly this:
       https://claude.ai/api/mcp/auth_callback

    This tells Salesforce where to send you back to after you log in and approve access — it must be typed exactly as shown. 6. Under OAuth Scopes, add these two:

    • Perform requests at any time (this is labeled refresh_token, offline_access internally) — this lets the connection keep working without you re-logging in constantly
    • Access Salesforce hosted MCP servers (labeled mcp_api internally) — this is the specific permission the Hosted MCP feature needs. Note: this is different from the general “api” scope you may have used for other integrations before — that one will not work here.
    1. Scroll to the Security section. This part trips people up, so read carefully:
      • Check (turn on): Require Proof Key for Code Exchange (PKCE) extension for Supported Authorization Flows
      • Check (turn on): Issue JSON Web Token (JWT)-based access tokens for named users
      • Uncheck (leave off, for this basic setup): Require Secret for Web Server Flow and Require Secret for Refresh Token Flow
      Why this matters: if you skip the JWT setting specifically, everything will appear to work — you’ll log in, approve access, and get redirected back successfully. But then every actual request Claude makes to Salesforce will fail with an error like INVALID_AUTH_HEADER or INVALID_JWT_FORMAT. This is confusing because the failure shows up later than the actual mistake, so it’s worth double-checking this checkbox specifically before moving on.
    2. Click Create (or Save) at the bottom.

    Step 3: Get your Consumer Key

    1. After saving, you’ll land on the app’s detail page. Click Settings, then find and expand OAuth Settings.
    2. Click Consumer Key and Secret.
    3. Salesforce will likely ask you to verify it’s really you — check your email inbox for a verification code and enter it.
    4. You’ll now see the Consumer Key (a long string of letters and numbers) and a Consumer Secret. Copy the Consumer Key somewhere you can find it again in a few minutes — a Notes app or a draft email works fine, this is not something you need to store in a password manager long-term. You generally won’t need the Consumer Secret for this particular setup, but it doesn’t hurt to copy it too just in case.

    Important — don’t skip this part: a brand-new External Client App can take up to around 30 minutes before it’s actually ready to use, even though it looks fully created. Salesforce compares this to how a newly registered website domain takes a little while to “propagate” before it works everywhere. If you try to connect from Claude right away and get an error like invalid_client_id, this delay is almost always why — it’s not something you did wrong. Grab a coffee and come back.

    Part 2: Inside Claude

    Step 4: Add Salesforce as a custom connector

    1. In Claude, find and click Customize (this is typically in the left-hand sidebar).
    2. Click Connectors.
    3. Click the + (plus) button.
    4. Click Browse connectors.
    5. Search for Salesforce and Click “+” in front of Salesforce – Beta from the list
    6. Paste the Consumer Key you copied in Step 3 into the field labeled OAuth Client ID.
    7. Click Connect.
    8. Claude will redirect your browser to Salesforce’s login page — specifically, the org that owns the External Client App you created.
    9. Log in with your normal Salesforce username and password (if you’re already logged into that org in the same browser, it may skip straight past this and go to the next step automatically).
    10. Salesforce will show you a screen describing what access is being requested. Review it and click Allow (or Approve).
    11. You’ll be redirected back to Claude automatically, and the connector should now show as connected/active.

    Trying it out for the first time

    Ask Claude something specific and concrete that only your live org would know the answer to — not a general Salesforce question, but something like “what’s the current stage of the [specific] opportunity” or “pull up the contact record for [a real name in your org].” If it responds with real, specific data from your org, it worked. If it responds generically or says it can’t access that, something in the setup needs a second look.

    If something’s not working, check these in order

    1. Is the MCP server actually activated? Go back to Setup → MCP Servers and confirm it shows as Active, not just listed.
    2. Does the Consumer Key match exactly? A single missed character will break the connection. Copy it fresh from Salesforce rather than retyping from memory.
    3. Has the 30-minute delay passed since you created the External Client App? This is the single most common reason things fail right after setup.
    4. Did you actually check both the PKCE box and the JWT box under Security in Step 2? Both need to be on.
    5. Is the Server URL exactly right, including /sandbox/ if (and only if) you’re connecting to a sandbox rather than production?

    A closing note on access and safety

    It’s tempting to activate every available MCP server and grant full read/write access right from the start, so you never have to come back and do this again. Resist that. Claude only has whatever access your authenticated Salesforce user already has — it can’t see or do more than you personally can — but an AI assistant that’s able to edit or delete real records is a meaningfully bigger responsibility than one that can only look things up. Start with read-only access, get comfortable with how it behaves, and widen permissions deliberately if and when you actually need to.