Category: Uncategorized

Salesforce has had its own models in Agentforce for a while now, Atlas for reasoning, a growing stable of smaller task-specific models underneath. The Anthropic partnership isn’t Salesforce replacing any of that. It’s Salesforce opening the model layer so Claude sits alongside its own models as an option you can point an agent at, inside Model Builder and reachable from Prompt Builder and Agent Builder. For a technical lead, that’s the part worth understanding properly, because “which model” is quietly becoming a design decision you make per agent, not a platform default you accept.

What actually changes on the ground

Practically, a Topic or an Action in Agentforce can now call a Claude model for the reasoning step instead of Salesforce’s own. You pick this in Model Builder, test it against your actions, and swap it back if it doesn’t help. Nothing about Flow orchestration, Data Cloud grounding, or the Einstein Trust Layer changes underneath it. The model choice sits at one layer; everything else in your agent architecture stays exactly where it was.

That matters because it’s tempting to treat “add Claude” as a quality upgrade you flip on everywhere. It isn’t. Some agent actions are closer to pattern matching than reasoning: classify this case, extract this field, pick one of four known intents. A smaller, cheaper model handles those fine, and the extra reasoning depth of a frontier model buys you nothing but latency and cost. Where it earns its keep is multi-step reasoning: an agent working through a messy support conversation, deciding which of several actions applies, holding context across a longer exchange, or handling instructions with real nuance rather than a fixed decision tree.

Where I’d actually reach for it

• Agents fielding open-ended customer input where intent isn’t obvious from keywords
• Multi-topic agents where the wrong routing decision is expensive to get wrong
• Actions that need to follow a long, conditional instruction set rather than a short prompt
• Anything where you’ve already tuned the Salesforce default model and it’s still making reasoning errors, not formatting errors

If your agent’s failures look like “it picked the wrong tool” or “it missed a condition buried in the instructions,” that’s a reasoning gap a stronger model can close. If the failures look like “it hallucinated a field that doesn’t exist” or “it ignored grounded data,” that’s usually not a model problem at all. That one sits with your retrieval setup and your Data Cloud grounding, and no amount of model swapping fixes bad context going in.

The governance story doesn’t move

This is the bit worth being explicit about with anyone nervous about “an external AI company’s model inside our CRM.” The Einstein Trust Layer still sits in front of every model call, Salesforce’s own or Claude’s. Prompt masking, data retention commitments, audit trails: none of that changes because the underlying model changed. What changes is which vendor processes the prompt once it clears that layer. If your organisation has already done the work of understanding what the Trust Layer promises and what it doesn’t, you don’t need a second security review just because an action now calls Claude. You do need to confirm that promise still holds for your specific org and contract, because trust layer behaviour has shifted before and will again.

Where I’d actually slow down is PII handling in the prompt itself. Grounding an action against a record that includes sensitive fields means that data is now flowing into a prompt regardless of which model answers it. That’s a data minimisation problem, not an Anthropic-versus-Salesforce problem, and it existed before this partnership. The partnership just makes it a live question again because teams are re-opening prompts to test the new model option.

What doesn’t carry over cleanly

Prompt engineering isn’t fully portable between models, and this is the part that catches teams out. An instruction set tuned carefully against Salesforce’s default model can behave differently against Claude, sometimes better, sometimes worse, rarely identical. Different models respond differently to how instructions are structured, how much context they’re given, and how explicit you are about edge cases. Swapping the model under an agent and assuming the prompt still performs the same way is the single most common mistake I’d expect teams to make here. Treat a model swap as a change that needs its own test pass, not a drop-in replacement.

How to actually evaluate it

Don’t eyeball a handful of test conversations and call it done. Build a small evaluation set per Topic, real examples of the inputs that action needs to handle well, including the ones that currently trip it up. Run that same set against both models, score the outputs against what a correct answer actually looks like, and compare. This is maybe twenty to thirty minutes of setup for a Topic that already exists, and it turns “Claude feels better” into something you can actually defend in a change review.

Watch latency too, not just accuracy. A reasoning upgrade that adds a second or two per response is invisible in a Slack-style async agent and very visible in a live chat widget a customer is staring at. Contact-centre agents in particular live or die on response time, and a model that’s measurably better on your eval set but noticeably slower in a live chat context isn’t automatically the right trade.

None of this is really about Anthropic specifically. It’s about Salesforce finally making model choice a first-class design decision inside Agentforce rather than something baked into the platform you can’t touch. That’s the actual shift. Treat it as one more lever in agent design, test it the way you’d test any other configuration change, and resist the instinct to flip it on everywhere just because a stronger model is sitting there available.

Every Salesforce org I’ve walked into with a messy security model has the same root cause. Someone conflated three different jobs, object permissions, record visibility and user-specific access, and tried to solve all three with one tool. Usually that tool is profiles, cloned a dozen times until nobody remembers which one does what.

Three separate questions, one confused answer

Profiles, permission sets, sharing rules and role hierarchy sound like they’re competing for the same job. They’re not. Each one answers a different question, and the mess starts the moment you use one to answer a question it wasn’t built for.

Profiles answer: what can this type of user do, by default, everywhere? Object-level CRUD, field-level security, login hours, session settings, page layout assignment. One profile per genuinely distinct user type. Not one per exception.

Permission sets answer a narrower question: what does this specific user, or this specific group, need on top of their baseline? A support agent who also approves refunds. A team lead who needs bulk export rights the rest of the team doesn’t. Give them a permission set. Don’t clone the profile.

Sharing rules, org-wide defaults and role hierarchy answer something else entirely: which records can this user see, given what they’re already allowed to do to that object type? Object access and record access are not the same job, and treating them as interchangeable is where I see the most damage on a live org.

Why profile cloning gets out of hand

I’ve inherited an org with 40-odd profiles for around 200 users. Every time someone needed one extra permission, the fix was clone the profile, tweak it, assign it. Two years in, nobody could say with confidence what “Sales Rep – APAC – Senior – v3” granted versus “Sales Rep – APAC – Senior – v3 (copy)”. Field-level security had drifted between them. Page layouts were out of sync. Every release turned into an audit exercise before anyone felt confident nothing had broken.

The fix isn’t clever. It’s discipline: profiles map to genuinely distinct baseline roles in the business, and stay few. Everything incremental goes through permission sets instead. If you’re cloning a profile to add one field permission, you’ve picked the wrong tool.

Permission sets are the right unit of change

Permission sets work because they’re additive and composable. A user can hold a baseline profile plus five permission sets, and you can reason about each one on its own. Revoke one without touching the others. Assign one to twelve people without cloning anything.

Bundling with permission set groups

Permission set groups start to matter once you’re past a handful of permission sets per user. Bundle “Refund Approver” and “Escalation Handler” into a group named something the business actually recognises, assign the group, and stop making admins remember which five permission sets a senior agent needs. Muting permissions within a group is worth knowing too: you can include a permission set in a group and still switch off one specific permission from it. That’s the cleanest way to handle an “almost, but not quite” case without another clone.

Sharing rules aren’t a patch for object permissions

This is the mistake that costs the most later. A user can’t see records they should see, so someone writes a sharing rule to fix it, without checking whether the actual gap is object or field-level access. Sharing rules only grant additional record visibility on top of what the object permissions already allow. If the profile or permission set doesn’t grant Read on the object in the first place, no sharing rule will ever fix that. I’ve watched a team burn most of a day debugging a sharing rule that was never going to work, because the real problem sat one layer down.

Start with org-wide defaults set as restrictively as the business genuinely needs, usually Private or Controlled by Parent for anything sensitive. Let role hierarchy handle the natural case: a manager sees their team’s records because that’s how the org actually works. Reach for sharing rules only for the exceptions role hierarchy can’t express, ownership-based or criteria-based visibility across teams that don’t share a reporting line. Treat manual sharing as what it is: a one-off, temporary exception, not a standing part of your access model. If you’re explaining a business rule through a dozen manual shares, you’ve actually found a sharing rule or a public group you haven’t built yet.

A framework that holds up under pressure

When a new access requirement lands, I ask it in this order.

• Is this about what a user can do to a record type, or which records of that type they can see? Object permission versus record visibility, decide which one you’re actually solving before you touch anything.
• If it’s object permission: does every user with this profile need it, or just some? A baseline change to the profile, or a permission set for the subset.
• If it’s record visibility: does the role hierarchy already express this relationship? If yes, you’re probably done once org-wide defaults are set correctly. If no, is it consistent and rule-based, or a genuine one-off?
• Rule-based exceptions become sharing rules or public groups. One-offs become manual shares, and get reviewed later, not left forever.

None of this is exotic. It’s the same four questions on every project, and the orgs that stay clean are the ones where someone asked them before the first permission set existed, not two years and forty profiles later. That 40-profile org took three sprints to unwind safely, mapping every user to what they actually needed rather than what their historical profile happened to grant. Getting the model right up front costs an afternoon of discipline. Getting it wrong costs a migration project.