Agentforce Readiness: 5 Things Your Salesforce Org Needs Before You Start

Every Agentforce demo looks good. The product is genuinely impressive — an AI agent that can handle complex customer inquiries, look up order history, update records, hand off to a human when needed. It works exactly as advertised in the demo environment.

Then you try to build it in your actual Salesforce org and things get complicated.

Over the past year I’ve worked with companies at various stages of Agentforce adoption — some who nailed it, some who stalled out after months of work, and some who were smart enough to assess their readiness before committing. The companies that succeed aren’t necessarily smarter or better funded. They’re the ones who did the prep work first.

Here are the five things that consistently determine whether an Agentforce implementation succeeds.

---

1. Clean, Accessible Data in the Right Places

Agentforce agents retrieve information to answer questions and complete tasks. The quality of that retrieval is entirely dependent on the quality of your data. This seems obvious until you look at what’s actually in most Salesforce orgs.

What “clean data” actually means for Agentforce:

• Consistent field population. If your agents need to look up account status, that field needs to be populated reliably across records. A field that’s filled in 60% of the time will produce an agent that’s wrong 40% of the time.
• No duplicate records. Agentforce uses retrieval mechanisms that can surface multiple matching records. Duplicate accounts, contacts, and cases don’t just cause confusion — they can cause agents to retrieve and act on the wrong record.
• Structured over unstructured. Long-form notes fields, email bodies in tasks, and PDF attachments are difficult for agents to reason over without additional configuration. Information your agents need should live in structured fields whenever possible.
• Current data. An agent that retrieves a billing address that hasn’t been updated in two years is worse than useless — it’s actively harmful.

Before you start, audit:

• Are the fields your agents will need consistently populated across your record set?
• Is your duplicate management policy in place and enforced?
• Are the key objects agents will interact with (Accounts, Cases, Orders, etc.) accurately reflecting current state?
• Is sensitive data appropriately masked or excluded from agent-accessible objects?

The Data Cloud integration makes this even more important. If you’re grounding agents in unified profiles from Data Cloud, the quality of your ingested data becomes the floor for what agents can know about a customer. Garbage in, garbage out — at enterprise scale.

---

2. A Clear, Narrow Use Case (Not “AI Everywhere”)

This is where the most money gets wasted. Companies see Agentforce and immediately imagine it solving every customer interaction, automating every internal process, and replacing half the contact center. The ambition is understandable. The execution of that ambition, attempted all at once, almost always fails.

Agentforce is an agent platform, which means it’s only as good as the topics and actions you define. Topics define what the agent is allowed to help with. Actions define what it can actually do. Both require careful, explicit design. There’s no magic prompt that makes an agent suddenly good at handling returns, billing disputes, order tracking, and product recommendations simultaneously on the first deployment.

What a good initial use case looks like:

• High volume, well-defined. Order status inquiries, appointment scheduling, account updates — things your team handles hundreds of times per day with relatively consistent paths to resolution.
• Bounded scope. The agent knows what it can and cannot help with, and hands off cleanly when it hits the edge.
• Good data already exists. The information the agent needs to answer questions is in Salesforce, accurate, and accessible.
• Measurable success criteria. You know what “good” looks like — deflection rate, resolution time, CSAT — before you start.

Before you start, define:

• The single most valuable use case for an AI agent in your operation
• The 3–5 specific things the agent should be able to do within that use case
• The explicit handoff conditions (when does the agent escalate to a human?)
• How you will measure success in the first 90 days

Starting narrow is not a failure of ambition. It’s the strategy that gets you to a live, trusted agent that users actually use — which is the foundation for expanding scope. The companies that start with “AI for everything” are still in planning 18 months later.

---

3. Einstein Trust Layer Configuration and Data Governance

Agentforce runs on the Einstein Trust Layer, Salesforce’s framework for keeping data secure when it interacts with large language models. Understanding this layer — and configuring it correctly — is non-negotiable before go-live.

Here’s what the Einstein Trust Layer does:

• Data masking. Sensitive fields (SSNs, credit card numbers, medical identifiers) can be masked before data is sent to the LLM, and unmasked in the response. This needs to be configured. It doesn’t happen automatically.
• Toxicity detection. The layer screens LLM outputs for harmful content before they’re surfaced to users.
• Audit logging. All LLM interactions are logged in the Einstein Trust Layer audit log — critical for compliance and debugging.
• Zero data retention. Salesforce does not use your data to train models. Understanding and being able to articulate this to your legal and compliance teams is part of your implementation work.

Common mistakes:

The most common error I see is treating the Einstein Trust Layer as a checkbox rather than a configuration exercise. Teams assume it’s “on” and protecting them, without verifying that the right fields are masked, the audit log is being reviewed, and the data accessible to agents matches what’s been approved by legal and security.

If you’re in a regulated industry (healthcare, financial services, insurance), your legal and compliance teams need to be involved in Einstein Trust Layer configuration before a single user sees an agent response. This is not an IT conversation that happens in a vacuum.

Before you start:

• Have you identified which fields and objects contain sensitive data that agents will interact with?
• Is data masking configured for regulated data types?
• Have legal and compliance reviewed the Einstein Trust Layer documentation and approved the architecture?
• Is the audit log configuration in place?
• Have you tested what the agent does with edge case inputs (jailbreak attempts, out-of-scope requests)?

---

4. The Right Salesforce Org Permissions and Configuration

Agentforce is a relatively new product, and its permission model is still maturing. What I can tell you from recent implementations is that permission and configuration issues are responsible for more delays than almost anything else — and they’re entirely preventable.

What you need to verify:

Licenses. Agentforce requires specific licenses that are separate from your core Salesforce licenses. The licensing model has changed multiple times since launch. Make sure you know exactly which licenses you have, which features they unlock, and what’s included versus what requires an add-on purchase. This conversation needs to happen with your Salesforce AE before you scope the technical work.

User permissions. The users who will manage and configure agents need the right permission sets. The users who will interact with agents need different permissions. Get this sorted before you start building — discovering that your admin doesn’t have access to Agent Builder is a frustrating and avoidable delay.

Connected App configuration. If your agents will interact with external systems (your ERP, shipping provider, etc.), Connected Apps need to be properly configured. This is standard Salesforce integration work, but it needs to happen before you’re building agent actions that depend on it.

Named Credentials. External callouts from agent actions should use Named Credentials, not hardcoded credentials. This is both a security best practice and an Einstein Trust Layer requirement for external interactions.

Before you start:

• Verify your Agentforce license entitlements with your AE
• Confirm which Salesforce features are included (Data Cloud, Einstein, etc.)
• Assign and test permission sets for admin users who will configure agents
• Confirm Connected App and Named Credential setup for any external integrations
• Review your org’s current sharing rules — agent data access follows Salesforce sharing rules

---

5. An Internal Champion With Time and Authority

This one isn’t technical, but it kills more implementations than the technical issues combined.

Agentforce requires ongoing human involvement. Agents need to be monitored. Topics need to be refined based on real conversation analysis. Actions break when underlying Flows change. New use cases need to be designed, tested, and approved. None of this happens automatically, and none of it can be delegated to a part-time Salesforce admin who already has a full backlog.

A successful Agentforce implementation requires:

An internal product owner — someone with the authority to make decisions about what the agent can and cannot do, who has access to the right people to get approvals when needed, and who is actually invested in the outcome.

Dedicated time from a Salesforce admin — configuration changes, Flow updates, and permission adjustments happen regularly. This person needs Agentforce on their plate, not buried under other projects.

Executive sponsorship — not just budget approval, but an executive who will be accountable for the business outcome and who can remove organizational blockers when they appear (and they will appear).

A feedback mechanism — some way for the people using the agent (agents, customers, supervisors) to flag issues and provide input on performance. Without this, you’re flying blind.

Before you start:

• Who is the internal product owner for this agent?
• What percentage of whose time is committed to this project?
• Who has executive accountability for the outcome?
• How will you capture feedback from users of the agent?
• How will you monitor agent performance and flag issues?

---

The Honest Summary

Most companies are not ready to start building Agentforce on day one. That’s not a criticism — it’s a reality of where the platform is and what it requires from your organization’s data, governance, and people.

The readiness assessment work is the most valuable thing you can do before committing to an implementation. Not because it makes the problem go away, but because it tells you exactly what you’re dealing with — what you can start now, what needs to be fixed first, and what will take longer than you think.

If you’ve read through this list and found yourself checking every box, you’re in genuinely good shape and you’re ready to talk about implementation scope and timeline.

If you found yourself with significant gaps, that’s also useful information — now you know what to fix and in what order.

Either way, knowing is better than guessing. And building on a solid foundation is better than discovering problems after you’ve already launched.

---

Running through this checklist and want to talk through what you found? Schedule a free 30-minute consultation — I’ll give you an honest read on where you stand and what it would take to get you to a successful Agentforce deployment.