Common Salesforce Agentforce Mistakes and How Agencies Avoid Them

Agentforce lets an administrator create agents inside Salesforce using Agent Builder. Each agent gets topics, which describe the jobs it handles, and actions, which are the things it can do, such as running a Flow, calling Apex code or querying records. The Atlas reasoning engine decides which topic and action fit a request.

Agents draw on the Salesforce Data Cloud and the Einstein Trust Layer, which handles data masking and audit logging. Prebuilt agents exist for service, sales development and other roles, and they can be deployed on websites, in Slack and in other channels.

Pricing and packaging have changed several times since launch, including per-conversation and credit-based models. Ask your Salesforce account team for the current terms before you build a business case.

An agent that reads records will repeat whatever it finds. Duplicate accounts, outdated contacts, empty fields and free-text notes with conflicting information all lead to wrong answers delivered with confidence.

Agencies avoid this with a data readiness review before any build. They check duplicate rules, required fields, picklist values and knowledge article freshness for the specific objects the agent will touch. Fixing a few objects well is better than starting a full data cleanse that takes a year.

Topic descriptions and instructions tell the reasoning engine when to use each topic. If two topics overlap, such as “Order help” and “Delivery questions”, the agent picks inconsistently and customers get different answers to the same question.

• Write each topic around one job with a clear boundary.
• State what is out of scope in the instructions, not only what is in scope.
• Use real customer phrases from past cases to test classification.
• Keep the number of topics per agent small at launch.
• Name actions so their purpose is obvious to the next admin.

Agentforce includes a Testing Center for running batches of sample utterances. Use it with real phrases from your case history, not with tidy examples written by the project team.

Teams often focus on what the agent should do and forget what it must not do. Refunds above a set value, contract changes, anything involving personal data, and complaints that mention legal action should hand over to a person.

Permissions

Agents run with a user and permission set. Give them the narrowest access that lets them work. An agent with full edit rights on Opportunities can damage a pipeline report in minutes if an action misfires.

Escalation

Define handover to a human in the instructions and in Omni-Channel routing. The customer should not have to repeat themselves; the case summary should travel with the handover.

Deflection, meaning conversations closed without a human, is the easiest number to report and the easiest to game. An agent that frustrates people until they give up also deflects.

• Resolution rate, confirmed by no repeat contact within a set number of days.
• Customer satisfaction on agent-handled conversations.
• Escalation rate and the reasons behind it.
• Accuracy on a weekly reviewed sample of transcripts.
• For sales agents, meetings booked and pipeline created, not just emails sent.

Launching to every customer on day one leaves no room to learn. A better pattern is a pilot on one channel or one segment, with daily transcript review in the first weeks and a short list of issues fixed before the next expansion.

Change management matters too. Service reps need to know what the agent handles, how handover looks and how to flag bad answers. Without that, the human team quietly works around the agent and adoption stalls.

Some teams start with complex Apex actions for every task when a standard action or an existing Flow would do. Custom code needs developers to maintain and test, and every Salesforce release adds review work.

Start with prebuilt agents and standard actions, then add custom actions only where a gap is clear. The first version should be boring and reliable; clever features can follow once the basics hold up in daily use.

Projects end, agents do not. Products change, policies change and new case reasons appear. An agent nobody owns slowly gives outdated answers, and the decline is hard to notice because no single conversation looks broken.

Name an agent owner on the client side, usually a service operations lead or Salesforce admin. Give them a monthly routine: review a transcript sample, check escalation reasons, update knowledge articles and retest topics after each Salesforce release.