Recently I posted on LinkedIn about how much I love Slackbot. One commenter replied that they weren't getting good results from it at all. Same tool, opposite verdicts. That really stuck with me, and in the weeks since I've thought about it often.
I think I know the reason for the disparity. I don't think the difference was the tool. I think it was what the tool had to work with, and there's a trap hiding in that difference that I've watched smart Salesforce practitioners walk into.
You store some important content in Salesforce. I'm not talking about structured data; I'm talking about long-form text, unstructured language, the real messy stuff. Maybe it's a long text field on a custom object, maybe a rich text field holding policies or FAQs. You type a keyword into global search, and there it is. Found it. That's what I mean by searchable: Salesforce's global search can find it when a person types the right words. So when the conversation turns to putting an AI agent in front of your staff or your constituents, you check that box too: our content is in Salesforce, it's searchable, the agent can use it.
That assumption is half right, which is what makes it a trap. Whether searchable content is ready for AI depends on which AI is doing the reading. Some AI tools work happily from search. Others need content deliberately prepared for them, on a different index with different rules. Content can pass one test and fail the other without anything looking broken.
Two Indexes, Two Contracts
Global search is built to help a person find a record. It matches your keywords, hands you a list, and trusts you to open the right one and read it in context. If the record is a bit messy, you cope. You're a human, after all; that's your superpower.
Agent grounding works differently. When an Agentforce agent answers a question from your content, it isn't opening records the way you do. It's pulling relevant passages out of a separate retrieval index, built for it ahead of time, and composing an answer from those passages. The technical name is retrieval-augmented generation, or RAG, but you don't need the term. You need the consequence: the agent can only use what has been deliberately prepared for retrieval. Showing up in global search doesn't put content in that index.
So, “Is it searchable?" is the wrong readiness question. The right one is: has this content been set up as a grounding source for the agent, with rules I've chosen about who can see what?
Your Slackbot Isn't Wrong
If your team uses Slackbot, you might be reading this and thinking: but my Slackbot finds everything. You're probably right. Ours does too, and it's how most of our team works with our knowledge base every day.
That's because Slackbot reaches Salesforce differently. For Salesforce records, it doesn't read from an index someone prepared ahead of time. It asks your org live, as you: Salesforce checks your access and returns only what you're allowed to see, and Slackbot does its own reasoning over whatever comes back. For an assistant working on behalf of someone already inside your organization, searchable gets you most of the way to readiness.
An agent that answers on your behalf to people outside your organization is a different job. Your clients and constituents aren't in your Slack, may not be logged in at all, and shouldn't see everything your internal users can. Even the ones who share channels with you are out of luck: Slackbot isn't available to Slack guest users at all. That agent needs a grounding source you've prepared on purpose and scoped to its audience. That's the build we're working through now for our own client-facing Knowledge agent, and it's the top rung of the ladder below.
There's a control difference, too. Through Slack's standard connection to Salesforce, Slackbot can't be restricted to less than the asking user's own permissions; capping it lower means connecting it through Salesforce's MCP servers instead. For your staff, inheriting their access is exactly right, and it's a big part of why it works so well. For an agent facing the public, that model is exactly wrong. You want that agent to see less than any one of your people can, and that has to be designed in.
So the real question isn't whether your content is searchable. It's which AI is asking, and what job you're giving it.
Three Rungs: Finder, Coworker, Guide
It helps to think of AI and your knowledge as a ladder. Each rung is a different job, and each asks more of your content than the one below it.
| Rung | The AI's job | What "ready" requires | Whose permissions |
|---|---|---|---|
| 1.Finder | Finds things for you | Content exists and is searchable | Yours |
| 2.Coworker | Recalls, combines, and acts on knowledge with you | Structure the model can reason with: clear record types, deliberate fields, a consistent way of organizing articles | Yours |
| 3.Guide | Walks someone outside your organization through something, on your behalf | A deliberately prepared grounding source, scoped to its audience and kept current | Designed for the agent, and narrower than any staffer's |
Two things about the ladder are worth knowing before you climb it.
The rungs build on each other. A Guide needs everything a Coworker needs, plus scoping and governance. A Coworker needs everything a Finder needs, plus structure.
The rungs are jobs, not products. Slackbot can be a Finder or a Coworker depending on what you ask it. It's included in Slack's Business+ and Enterprise+ plans, but only Enterprise+ gets unlimited use; Business+ comes with a weekly message limit (15 per user when we ran the cost scenarios). And if you don't have (enough) Slackbot, an internal Agentforce agent can fill the Coworker rung for your staff. It just means doing more of the Guide-style setup, like building a Data Library, to get there. This in itself is an implied argument for considering an upgrade to Slack Enterprise+ to unlock an unmetered, unlimited Slackbot. We did exactly that as a five-person team, and wrote about why. #NoRagrets
The Coworker Rung: Make Your Fields Deliberate
This is where our own Slackbot earns its keep. Our team doesn't just ask it to find articles. We ask it what we've said about a topic, and we turn procedure articles into action steps and checklist articles into activity tasks. That works because our knowledge base was organized long before any AI showed up, on habits I learned in the military. (Where those habits came from is the subject of our next post.) We told the story of our first week with Slackbot in Slackbot Rocks Part 2, including the lesson I'd hand any admin first: Slackbot is a mirror. Whatever state your workspace and your Salesforce are in, it reflects right back at you.
When Slackbot searches, records come back and the model has to make sense of them. Structure is what lets it reason instead of guess. A few practical configuration choices do most of the work:
Give every field one meaning. A field that means two things depending on context forces the model to guess which one you meant.
Give every article a place. Each of our articles look up to a parent "map" record. The map's label, its position in a numbering scheme where the numbers themselves mean something, and its sibling articles all tell a reader where an article sits before they read a word. Our numbering is borrowed from the Navy, and the next post explains why that matters.
Link what belongs together. Related-article links, and especially a clear signal when one article replaces another, keep the model from confidently quoting last year's policy.
Keep dates and status honest. "Current" should be something a model can check, not something it has to assume. We hold our Slackbot Skills to the same standard, with an owner, a version, and retirement criteria for each (more on that governance here).
None of this guarantees the model uses every clue every time. But it makes the clues available, and a model with clues guesses less. We've made the same argument about Slack itself: your channel model is Slackbot's map of your business. Your Knowledge ontology is its map of what you know.
The Guide Rung: What Changes When the Agent Answers for You
In Agentforce, that preparation runs through an Agentforce Data Library. Salesforce's own training describes the Data Library as supporting Knowledge articles, uploaded files, web search, and custom retrievers, and Data Cloud has to be turned on before you can build one. Those sources are not equally easy to get right.
| Where your content lives | How it reaches the agent | Who does the work |
|---|---|---|
| Salesforce Knowledge articles | A Data Library set to Knowledge. You pick the fields to index and can limit it to public articles. | Mostly configuration, with documented guidance from Salesforce |
| Files (PDFs, docs) | Uploaded into a Data Library | Light setup, but think hard about access before uploading anything that isn't public |
| Public web pages | Web source in a Data Library | Light setup, public content only |
| Custom object fields, including rich text | A Data Cloud search index plus a custom retriever you build | You. Design, permissions and testing are yours to own. |
That last row is where the searchable-but-not-ready content tends to live. It can absolutely be grounded. But it's a build project, not a checkbox, and it doesn't happen just because the field shows up in global search.
Knowledge sits at the other end of the table. Salesforce calls the Data Library an advanced grounding tool for Knowledge, and its own guidance frames a Knowledge base as the trusted data layer for service reps and AI agents. It's the path the platform was designed around. We'd know. Years ago, we rejected Salesforce Knowledge as clunky and built our knowledge base in Confluence instead. Agents brought us back. It's the same lesson behind why we walked away from Jira: some things you only learn by running your business on them, and that experience sent us back to doubling down on Salesforce. The structure we'd written off as clunkiness turned out to be exactly what an agent needs.
What We Actually Built (and What We Learned)
We track our own long-form marketing content in Salesforce on a custom object. That's where drafting happens: tasks, approvals, and the automation that moves a post from idea to published. When we wanted our published posts to be findable by an agent, the obvious move was a rich text field on that object with the post pasted in. It would be searchable, it would sit right next to the tracking data, and it would take ten minutes.
What we actually wanted was to ask an agent "Have we written about this?" and get back what we said, when we said it, and where it's published. A rich text field would have made each post searchable on day one, but it wouldn't have made it an answer. The content would sit among drafts and event announcements, with nothing marking it as something we stand behind, trapped in a field our agent couldn't use without a custom retriever we'd have to build ourselves.
So we split the jobs. Our content object keeps doing the work: planning across channels, reviews and approvals, task automation, and mapping each piece to our pillars and campaigns. Plenty of what moves through it, like event announcements and the occasional funny post, never needs to be found again. The posts that do get captured in Knowledge as a Resource article, the same record type we use for external links, work aids, and sites worth keeping.
A Resource is a different kind of record. It says: this link is useful, good and true, it belongs here in how we organize what we know. Further, it says that if we wrote it, we should remember that we said it, and what we said. It doesn't hold the whole post, just a pointer back to it. Keeping workflow and findability on separate records means neither one gets bent out of shape to serve the other's purpose.
Designing it taught us the most important part. As far as we can tell, a Data Library indexes the fields on the article; it doesn't follow the link and read the page. A pointer article is only as findable as its summary. Write "a post about AI readiness" and the agent can barely find it. Write what we actually argued, in a plain text field the library indexes, and the agent can find the post, state our position, and hand over the link so the reader gets the full argument.
This post will get the same treatment. Once it's published, its Resource summary will read something like: Whether Salesforce content is AI-ready depends on which AI is asking. Search-based assistants like Slackbot work from findable, well-structured records using each person's own access; client-facing Agentforce agents need a deliberately prepared, scoped Data Library. Deliberate fields and structure help both.
Even Knowledge isn't Automatic
Moving content into Knowledge is the right first move, but it's not the finish line. Four things decide whether a Knowledge article actually helps your agent.
It has to be published. A Data Library indexes published articles. A great draft sitting in review is invisible to the agent.
The right fields have to be indexed. When you set up the library, you choose which fields the agent can search and read. Put the substance of an article in a field you didn't select and the agent never sees it. Field type matters too: content fields are limited to text and text area types, so when you add a field meant for grounding, make it a plain Long Text Area rather than rich text. On a pointer article like ours, that one short summary field does more for retrieval than anything else on the record.
Scope has to match the audience. A public-facing agent can be limited to articles marked for public visibility, and you can filter by data category. Those settings are how you keep internal policy out of a customer conversation.
Permissions have to line up. For agents running as a signed-in user, Salesforce applies that user's access to the articles behind each answer. Miss a permission and you usually won't get a leak. You'll get an agent that answers nothing, which is its own support headache.
None of this is exotic. It's the same work that makes a knowledge base good for people: clear articles, kept current, with a deliberate answer to who should see this? The difference is that a human reader forgives a messy article. An agent repeats the mess with confidence.
Messiness has a price on this rung, though maybe not the one you'd expect. Agentforce bills per action, not per word read, so an answer drawn from a messy article doesn't cost more than one drawn from a clean one. It's just worse quality. And worse answers cost more turns: the follow-up question, the rephrase, the second retrieval, the handoff to a person. Each of those is another action.
One more tip if you've built an ontology like ours. As far as we can tell, a Data Library indexes the fields on the article itself and won't follow a lookup out to a parent record. If your structure lives on a related object, bring the essentials onto the article, for example a plain text field that carries the parent's label and number, kept current by a Flow. Otherwise the organization your Coworker relies on may be invisible to your Guide.
A Five-Minute Test for Monday Morning
Pick the three pieces of content you'd most want an AI to answer from: your top FAQ, a key policy, your program eligibility rules. For each one, start with the question this whole post turns on: which rung is asking? A Finder, a Coworker, or a Guide? Then ask:
Where does it actually live? A Knowledge article, a file, a field on a custom object, or somebody's Google Drive?
Is it in a grounding source? Not "can I search for it," but "is it in a Data Library or a retriever someone built on purpose?"
Who should see it? Staff only, signed-in constituents, or the public? Is that rule written into Salesforce, or just understood?
Is it current? If an agent quoted it to a donor tomorrow, would you stand behind every sentence?
If you answered "custom field" to the first question and "I'm not sure" to the second, you've found your AI readiness gap. That's good news. It's a content and architecture problem, and those are fixable long before anyone launches an agent.
The agent gets the headlines. The content behind it decides whether it can be trusted. Searchable got you this far. Ready takes a deliberate step more.
Next up: "AI Is Just a New Kind of Reader." Our knowledge base grew out of the military's discipline of shaping every message for whoever receives it, Navy numbering and all, long before AI entered the picture. In the next post, I'll show you how that discipline made us AI-ready before we knew we needed to be, and why it turns out an AI is just a new kind of reader.
References
Use Knowledge in Agentforce for Service (Trailhead)
Prepare Your Salesforce Knowledge Base (Trailhead)
agent adl update, Salesforce CLI reference (content fields and public-articles restriction on Knowledge libraries)
Get Started with Slackbot (Trailhead; Slackbot respects your Salesforce access)
A Deep Dive Into Slack and Salesforce Integrations for Salesforce Architects (Salesforce; Slackbot reasoning and permission limits)
Agentforce Flex Credits pricing announcement (Salesforce, May 2025)
Slackbot features and plans (Slack; Business+ weekly limit, unlimited on Enterprise+)
